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FOREWORD 


BACKGROUND 

The  Naval  Command,  Control  and  Ocean  Surveillance  Center’s  RDT&E  Division 
(NRaD)  supports  the  Marine  Corps  through  the  Battlefield  Electronic  Support  Technology 
Program.  The  principal  objective  of  this  program  is  to  enable  the  Marine  Corps  to  develop 
technology  leading  to  high-performance,  portable  Command,  Control,  Communications 
and  Intelligence  (C3I)  systems. 

OVERALL  OBJECTIVES 

In  the  3900/AW/4  Feb  92  letter  from  the  Marine  Corps  Research,  Development  and 
Acquisition  Command  (now  the  Marine  Corps  Systems  Command),  tasking  was  given  to 
NRaD’s  Copernicus  program  office.  Subsequent  meetings  between  NRaD  and  the  Sys¬ 
tems  Command  resulted  in  the  following  specific  tasks  addressed  in  this  report: 

Identify  architectural/technical  issues  associated  with— and,  when  possible,  provide 

solution/options  for— 

1.  The  Marine  Air-Ground  Task  Force  (MAGTF)  Command  Element  (CE)  to 
function  as  a  Tactical  Command  Center  (TCC)  within  the  Navy’s  Copernicus 
architecture. 

2.  A  shipboard  interface  between  the  Marine  Tactical  Command  and  Control  Sys¬ 
tem  (MTACCS)  and  the  Navy  Tactical  Command  System-Afloat  (NTCS-A) 
C3I  system. 

3.  Use  of  “Communications  Support  System  (CSS)-like’’  architecture  and  technol¬ 
ogy  to  support  the  communications  resource-allocation  requirements  of  a 
MAGTF  CE  ashore. 

Note  that  the  systems  and  concepts  discussed  here  (Copernicus,  NTCS-A,  et  al.)  will 
likely  be  subject  to  significant  changes  over  time,  particularly  in  this  present  environment 
of  budgetary  constraint  and  changing  threats.  For  this  reason,  some  of  the  assumptions 
made  in  this  document  about  these  programs  are  “best  guesses, 
based  on  them  may  have  to  be  modified  in  the  future. 
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SCOPE/DOCUMENT  STRUCTURE 


As  indicated  by  the  task  objectives  just  described,  the  treatment  of  the  elements  cov¬ 
ered  in  this  report  varies  from  considering  near-term  solution/options  to  an  existing  com¬ 
munications  problem— to  a  very  much  more  theoretical  identification  of  issues  associated 
with  treating  the  MAGTF  CE  as  a  TCC  in  Copernicus. 

To  accommodate  this  variation  and  the  differing  operational  context  of  each  task,  this 
report  addresses  the  task  elements  in  the  following  order: 

1.  MTACCS/NTCS-A  Shipboard  Interface  (Section  1) 

2.  MAGTF  CE  to  Function  as  a  TCC  (Section  2) 

3.  “CSS”  to  Support  MAGTF  CE  Ashore  (Section  3) 

Recommendations  and  conclusions  are  provided  separately  for  each  task  element  at 
the  end  of  each  section. 

Appendix  A  provides  a  succinct  description  of  the  Navy-developed  C3I  systems  men¬ 
tioned  in  this  report.  Appendix  B  presents  an  overview  of  Copernicus  and  its  relationship 
with  MTACCS,  and  Appendix  C  lists  some  CSS-related  terms  and  definitions. 
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1.  MTACCS/NTCS-A 
SHIPBOARD  INTERFACE  TASK 


1.1  ARCHITECTURAL  LAYOUT 


1.1.1  Operational  Context 

Amphibious  operations  are  acknowledged  to  be  among  the  most  complex  and  difficult  of 
military  operations.  To  be  successfully  accomplished,  an  ongoing  dialogue  must  exist 
between  the  Marine  Air-Ground  Task  Force  (MAGTF)  Command  Element  (CE)  and  the 
Navy’s  Command  Element  represented  by  the  Commander,  Amphibious  Task  Force 
(CATF)  throughout  the  entire  assault  operation.  The  requisite  information  and  data- 
exchange  requirements  and  resources  will  clearly  vary  during  the  phases  of  the  operation. 
While  both  the  Commander,  Landing  Force  (CIJ)  and  the  CATF  are  embarked,  prior  to 
the  start  of  an  assault,  the  communications  and  data-exchange  requirements  between  the 
Navy  and  the  Marine  Corps  must  be  identified.  Once  identified,  many  or  all  of  these 
requirements  could  be  accommodated  by  an  interface  between  the  Marine  Corps’ 
MTACCS  and  the  Navy’s  NTCS-A  systems.  This  section  addresses  this  interface  (fig¬ 
ure  1-1)  and  the  architectural  and/or  technical  issues  associated  with  it. 


C2  FOR  OTH  ASSAULT 
ATF/LF  INTERCONNECTIVITY 


1.1.2  NTCS-A  Connguration  (See  Appendix  A.) 

The  NTCS-A  hardware  configurations  in  figures  1-2  and  1-3,  taken  from  the  NTCS-A 
Program  Handbook  of  21  October  1991,  reflected  current  planning  for  amphibious  assault 
(LHA/LHD)  ship  equipment  locations  and  are  the  system  architectures  considered  in  this 
study.  (These  figures  illustrate  the  density  of  the  hardware  in  the  two  configurations.)  The 
following  list  comprises  the  Navy  Tactical  Command  Systems-Afloat  (NTCS-A)  stan¬ 
dards  that  are  assumed  with  these  architectures  and  that  define  the  system’s  “Common 
Operating  Environment”  are 

Operating  System  UNIX  (POSIX) 

Database  RDBMS,  SQL 

Languages  C,  Ada 

Local  Area  Network  Ethernet  802.3 

Protocols  TCP/IP  (GOSIP) 

Graphics  GKS,  PHIGS 

Man-Machine  Interface  X- WINDOWS  (MOTIF) 


Figure  1-2.  NTCS-A  hardware  configuration,  LHD. 
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Figure  1-3.  NTCS-A  hardware  configuration,  LHA. 

1.1.3  Specific  MTACCS  Configuration 

The  specific  MTACCS-hardware  configuration  and  architecture  used  in  this  study  are 
based  on  the  recommendations  in  the  Hardware/Software  Architecture  Recommendations 
for  Marine  Corps  Tactical  Command  and  Control  System  (MTACCS)  Report  of  May  1991 
by  Pacific  Northwest  Laboratory.  It  presumes  the  elements  of  MTACCS  (TCO,  MILOGS, 
IAS,  etc.)  are  running  as  applications  on  the  four-layered  structure  as  shown  on  fig¬ 
ure  14.  Specific  LHA/LHD  architectures  like  those  shown  for  the  NTCS-A  above  are  not 
available  at  this  time,  but  certainly  one  can  assume  that  MTACCS  could  be  similarly 
configured  in  a  shipboard  environment.  The  revised  Operational  Requirement  for  the 
Intellegence  Analysis  System,  for  example,  describes  a  configuration  consisting  of  a  data 
storage  device,  several  workstations,  and  printers,  tied  together  by  a  local  area  network.  It 
states  that  the  Integrated  Avionics  System  (IAS)  shall  be  interoperable  with  U.S.  Navy 
intellegence  systems  aboard  amphibious  shipping,  with  Intellegence  Support  to  Strike/ 
Amphibious  Forces  (ISS/AF),  and  with  Tactical  Flag  Command  Center  (TFCC)  intelli¬ 
gence  systems,  thus  keeping  the  MAGTF  database  current  through  all  phases  of  an 
amphibious  operation.  The  requirement  also  postulates  that  the  equipment  will  be  used  in 
Joint  Intelligence  Center  (JIC)  spaces  when  possible.  Other  MTACCS  elements  are  even 
less  specific  about  their  particular  architecture  aboard  ship. 

1.1.4  Other  Concerns  About  Architecture 

Issue— Proliferation  of  Marine  Corps-related  NTCS-A  interfaces. 

As  the  individual  components  of  MTACCS  continue  in  their  separate  development  pro¬ 
grams,  each  element  has  stated  a  requirement  to  interface  with  NTCS-A.  Additionally, 
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Figure  1-4.  Elements  of  MTACCS  running  as  applications  on 
four-layered  structure. 

Marine  Corps-related  Navy-developed  C2  systems  (discusssed  ahead)  plan  to  interface  as 
well.  Unless  the  interface  development  is  done  in  a  planned/coordinated  manner,  Marine 
Corps  requirements  probably  will  not  be  met  in  a  cost-effective  manner,  if  at  all. 

Three  other  ongoing  system-development  programs  involve  shipboard  amphibious 
operation  information  and  data-exchange  needs  and  methods.  Two  of  these  are  being 
developed  by  the  Navy:  the  AN/KSQ-1  Amphibious  Assault  Direction  System  and  the 
Tactical  Information  Processing  System  (TIPS),  both  described  in  Appendix  A.  The  other, 
being  developed  by  the  Marine  Corps,  is  the  Amphibious  Assault  Planner  (AAP).  These 
systems  are  designed  to  provide  support  for  the  CATF/CLF  and  thus  directly  affect  the 
requirements  and  design  of  an  MTACCS/NTCS-A  interface. 

1.1.5  Architectural  Layout 

These  paragraphs  present  basically  two  different  architectural  concepts  for  the  shipboard 
Marine/Navy  Command  and  Control  Interface.  Each  concept  implies  a  different  philoso¬ 
phy  involving  responsibility  for  meeting  Marine  Corps  C2  requirements  during  an 
amphibious  operation,  leading  to  a  significantly  different  Concept  of  Operations.  Techni¬ 
cal  pros  and  cons  cc  .cerning  each  of  these  concepts  are  discussed  in  the  Conclusion  and 
Recommendations  part  of  this  section. 

Concept  1— Integrate  Marine  Corps  Shipboard  Needs  Within  NTCS-A  and  Other  Navy 
Systems 

This  architecture,  reflected  in  figure  1-5,  postulates  that  MTACCS-unique  hardware 
would  not  be  required  shipboard  to  support  Marine  Corps  C2I  needs.  Their  command  and 
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control  assets  would  be  handled  similarly  as  communications  assets  are  now  treated,  the 
Navy  being  responsible.  Specific  Marine  Corps  C2  requirements  would  be  met  by  Marine 
Cotps-devLped  software  (i.e.,  MTACCS  software)  that  runs  as  application  programs  in 
the  NTCS-A  software  and  hardware  environments.  Additional  workstations  could  be 

added  as  required. 


Figure  1-5.  Gateway  concept  for  interface  shipboard. 


Concept  2-NTCS-A  and  MTACCS  Shipboard  System  Interface 

This  architecture,  also  shown  notionally  in  figure  1-5,  postulates  an  independently  devel¬ 
oped  MTACCS  used  shipboard.  The  illustration  should  not  imply  that  either  NTCS-A  or 
MTACCS  will  exist  in  a  ring  architecture,  but  that  it  illustrates  the  “gateway  concept  for 
the  interface  shipboard.  The  complexity  of  the  gateway  depends  upon  the  amount  of 
information  flow  through  it,  the  type  of  information,  and  the  differences  in  architecture 
between  NTCS-A  and  MTACCS.  Using  this  structure,  the  networks  may  employ  different 
message  formats,  maximum  message  sizes,  and  character  sets.  They  may  use  completely 
different  addressing  methods.  This  would  allow  major  differences  in  protocols  and  stan¬ 
dards  to  exist  between  MTACCS  and  NTCS-A. 


Selecting  Concept  1  would  be  a  significant  change  from  the  current  direction  of  inde¬ 
pendent”  MTACCS-component  development.  This  could  significantly  affect  the  ongoing 

design  work  of  MTACCS  systems. 
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Issue— How  would  selection  of  the  architecture  impact  existing  development  work  of 
MTACCS  component  systems? 

1.2  TASK  ANALYSIS/ISSUES  IDENTIFIED 

1.2.1  Information  Requirements  Between  CATF/CLF  in  a  Shipboard  Environment 

Information  needs  between  CATF/CLF  on  the  ship  fall  generally  into  three  distinct  but 
not  fully  independent  categories.  These  are  Planning,  Communications,  and  Tactical. 

Marine  Corps  planning  needs  in  the  shipboard  environment  will  involve  preparing  and 
updating  databases  for  both  administrative  and  tactical  use,  as  well  as  modifying  previ¬ 
ously  developed  operational  procedures  and  plans,  and  updating  intellegence  and  logistic 
information.  To  define  information  flow  needed  between  NTCS-A  and  MTACCS  in  the 
planning  area,  however,  assumes  that  a  previously  arranged  understanding  has  existed 
about  the  location  of  planning  data  between  the  Navy  and  Marine  Corps  system.  This 
understanding  is  a  “Concept  of  Operations  for  Afloat  Planning,”  using  MTACCS  and 
NTCS-A/KSQ-l/nPS  systems.  It  has  not  been  addressed  by  either  the  Navy  or  the  Marine 
Corps  and  has  led  to  parallel  system  requirements.  Generalizing  even  further,  a  Concept 
of  Operations  for  the  Marine  Corps/Navy  amphibious  operation  is  required  to  rationally 
determine  system  and  system-interface  requirements.  The  Concept  of  Operations  would 
map  Marine  Corps  and  Navy  operational  requirements  in  all  those  areas  just  discussed  to 
the  particular  equipment  that  the  services  have  available. 

Issue— Concept  Of  Operations  Development 

1.  Run  Marine  Corps  C^  as  applications  in  the  NTCS-A  environment,  i.e.,  com¬ 
plete  integration  shipboard. 

2.  Run  Marine  Corps  in  MTACCS-developed  hardware  and  software.  Interface 
(gateway)  for  any  desired  information  transfer. 

The  Concept  of  Operations  just  discussed  follow  directly  from  the  architecture  options 
previously  mentioned. 

1.2.2  Issues  Associated  With  Meeting  Requirements 

Based  on  the  issues  just  discussed,  requirements  for  Marine  Corps  C2I  can  be  viewed  in 
two  ways,  each  reflecting  the  alternative  Concept  of  Operations/architectures  for  the  ship¬ 
board  interface. 

Issue— What  additional  information  and/or  capability  is  needed  in  NTCS-A  to  support 
the  Marine  Corps?— or— What  information  is  NTCS-A  holding  that  requires  the  Marine 
Corps  (MTACCS)  to  support  MC-C2I  functions  shipboard? 

Another  “architecturar’-related  requirement  relevant  to  discuss  here  is  the  need  to  transi¬ 
tion  from  NTCS-A  support  to  MTACCS  support  during  the  later  portion  of  the  assault 
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and  subsequent  operations-ashore  phases  of  an  amphibious  operation.  MTACCS  tactical 
and  intelligence  databases  must  be  initialized  promptly  and  accurately  for  a  successful 
mission.  This  is  a  much  less  significant  technical  issue  if  the  Concept  of  Operations  re¬ 
flects  the  “gateway”  interface  architecture,  since  this  architecture  would  cause  these  data¬ 
bases  to  update  automatically. 

Issue— How  much  common  software  architecture  will  exist  between  MTACCS  and 
NTCS-A? 

The  complexity  of  the  interface  between  NTCS-A  and  MTACCS  local  area  networks  will 
be  driven  by  the  differences  in  their  software  architecture.  When  viewed  in  terms  of  the 
open-system  interconnection  (OSI)  reference  model  (figure  1-6),  the  use  of  a  simple  re¬ 
peater  as  an  interface  is  possible  when  protocols  associated  with  all  seven  layers  are  the 
same.  A  gateway,  on  the  other  hand,  would  be  necessary  if  these  protocols  were  different. 
If  the  “applications”  architecture  were  chosen  for  the  shipboard  NTCS-A/MTACCS  inter¬ 
face,  the  concern  of  the  unique  needs  of  the  Marine  Corps  becomes  a  major  design 
driver;  particularly  those  requirements  associated  with  presentation  to  the  user. 

Issue— How  stable  are  the  standards  and  protocols  that  define  the  NTCS-A  operating 
environment? 

This  issue  could  significantly  affect  all  developers  of  applications  programs  for  NTCS-A. 


1.3  CONCLUSIONS  AND  RECOMMENDATIONS 


Six  issues  have  been  identified  that  must  be  addressed  when  considering  the  design  of  a 
shipboard  interface  between  MTACCS  and  NTCS-A.  They  are 

1.  Proliferation  of  Marine  Corps-related  NTCS-A  interfaces. 

2.  Impact  on  current  MTACCS-component  software  development  depending  on 
the  choice  of  future  shipboard  architecture. 

3.  Concept  of  Operations  development. 

4.  Identification  of  specific  Marine  Corps  information  requirements  and  needs  in 
NTCS-A. 

5.  Common  software  architecture  and  operating  environment  between  MTACCS 
and  NTCS-A. 

6.  Stability  of  the  NTCS-A  operating  environment. 
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APPLICATION  LAYER 


PRESENTATION  LAYER 
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Figure  1-6.  OSI  reference  model. 

Issues  1  and  2  pertain  to  present  Marine  Corps  and  Navy  systems  developments.  TCO, 
IAS,  AAP,  and  other  systems,  like  AN/KSQ-1  and  TIPS,  have  specified  the  need  to  inter¬ 
face  with  NTCS-A.  Independent  development  of  these  interfaces,  as  is  now  happening, 
cannot  be  the  most  cost-effective  and  efficient  means  to  provide  for  them.  We  recom¬ 
mend  that  steps  be  taken  now  to  coordinate/standardize  NTCS-A  interface  design  across 
ongoing  Marine  Corps  C2  system  developments. 

Investigation  of  Issue  2,  which  would  determine  how  much  of  current  MTACCS- 
component  software  development  would  be  transportable  into  the  future  MTACCS, 
should  be  addressed  upon  resolving  the  following  issue  discussed. 

Issue  3  discusses  what  is  the  most  significant  decision  at  present,  since  its  resolution 
defines  the  philosophy  and  framework  for  future  MTACCS  development.  The  following 
discussion  deals  with  the  pros  and  cons  associated  with  designing  and  developing 
MTACCS  software  for  the  NTCS-A  operating  environment. 

A  common  MTACCS/NTCS-A  operating  environment  provides  these  advantages: 

1.  Allows  the  Marine  Corps  maximum  leverage  from  Navy  developments. 

2.  Provides  a  truly  “seamless  transition”  from  garrison  to  ship-to-shore  evolution 
of  an  amphibious  assault. 

3.  Does  not  require  complex  design  for  shipboard  interface. 
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4.  Provides  inherent  interoperability  with  Navy  C2  and  makes  design  issues— 
associated  with  interoperabilty  among  the  other  services— common  to  the  Navy/ 
Marine  Corps. 

The  disadvantages  of  a  common  MTACCS/NTCS-A  operating  environment  are  as  fol¬ 
lows: 

1.  Difficult  evolution  from  current  MTACCS  development. 

2.  Larger  and  more  difficult  Marine  Corps/Navy  coordination. 

3.  Loss  of  “independent”  development. 

4.  Greater  difficulty  in  treating  Marine  Corps-unique  requirements. 

5.  Competition  with  the  Navy  for  priority  for  upgrades  to  NTCS-A. 

We  believe  that  the  advantages  associated  with  a  common  environment  outweigh  the  dis¬ 
advantages  and  recommend  that  a  Concept  of  Operations  based  on  that  architecture  be 
developed.  This  concept  would  detail  specific  Marine  Corps/Navy  C2  system-interface 
requirements  and  would  additionally  clarify  the  role  of  the  MTACCS-  and  Navy-developed 
C2I  systems  through  the  stages  of  an  assault. 

Issues  4  and  5  would  be  addressed  in  the  Concept  of  Operations  development. 

To  adequately  resolve  Issue  6  requires  close  liaison  between  the  Navy  and  Marine  Corps. 
A  closer  interface  should  be  maintained  than  that  currently  provided  by  the  Fleet  Require¬ 
ments  Working  Group,  focused  on  design  versus  operational  issues.  We  recommend  that 
a  mechanism  be  established  to  maintain  an  ongoing  dialogue  between  MTACCS  and 
NTCS-A  developers. 

Table  1-1  summarizes  the  identified  issues  and  recommendations. 

Table  1-1.  MTACCS/NTCS-A  interface,  issues  and  recommendations. 


Issue  Recommendations 


1.  Proliferation  of  MTACCS 
interfaces  to  NTCS-A. 

2.  Impact  on  current  MTACCS 
by  choice  of  long-term  software 
architecture. 

3.  Concept  of  Operations 
development. 

4.  Marine  Corps  information 
requirements  in  NTCS-A. 

5.  Common  software  architecture 
and  operating  environment. 

6.  Stability  of  NTCS-A 
operating  environment. 


Standardize  the  interface.  (Use  Recommenda' 
tion  6.) 

Pending  Concept  of  Operations  development. 

Define  concept  with  common  MTACCS/ 
NTCS-A  environment. 

Part  of  Concept  of  Operations. 

Addressed  in  Concept  of  Operations. 

Establish  a  Marine  Coips/Navy  (MTACCS/ 
NTCS-A)  design  group. 
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2.  MARINE  AIR-GROUND  TASK  FORCE  COMMAND 
ELEMENT  AS  A  TACTICAL  COMMAND  CENTER 

2.1  TASK  DESCRIPTION 


2.1.1  Operational  Context  of  Task 

Figure  2-1  depicts  the  connectivity  requirements  of  this  task. 


C2  FOR  OTH  ASSAULT 


GLOBIXS 


GARRISON 

AFLOAT 

ASHORE 

TRANSITION 


Figure  2-1,  Operational  context  of  the  task. 


The  physical  MAGTF  TCC,  in  its  four  operational  states  (Garrison,  Afloat,  Ashore, 
and  Transition),  is  connected  via  the  Tactical  Data  Information  Exchange  Systems 
(TADKS)  to  the  CINC  Command  Center  (CCC),  to  Afloat  NTCS-A  configured  TCCs 
(CATF,  CLF,  Battle  Force),  and  to  other  TCCs  (Joint,  Army,  Air  Force).  These 
connectivities  are  required  to  perform  the  MAGTF  mission. 

As  in  any  tactical  information-processing  system,  time  will  tend  to  be  the  critical 
factor  for  the  MAGTF  TCC  and  the  supporting  information  networks.  MTACCS  and 
Copernicus  will  be  required  to  support  a  combination  of  planning  and  execution 
functions.  The  former  is  less  time-constrained,  tending  to  be  completed  separately  from 
the  realtime  battle,  while  the  latter  requires  near  realtime  performance. 
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2.1.2  Baseline  MTACCS  Configuration  (MCTCA-Midterm) 


The  baseline  MTACCS  configuration  and  required  connectivities  for  purposes  of  this 
study  are  the  Marine  Corps  Tactical  Communications  Architecture-Midterm  (MCTCA- 
Midterm). 

2.1.3  Detailed  Task  Description 

This  subtask  lays  out  the  MAGTF  architecture  in  terms  of  Copernicus  pillars,  and 
identifies  the  architectural  and  technical  issues  that  must  be  resolved  to  enable  the 
MAGTF  CE  to  function  as  a  TCC  within  the  Copernicus  architecture. 

Figure  2-2  depicts  the  MAGTF  architecture,  including  current  connectivity  (TADKS) 
requirements  among  the  CE  and  other  MAGTF  components— and  with  external  Command 
and  Control  Facilities  (C2FACS). 


CURRENT  CONNECTIVITY 


Figure  2-2.  MAGTF  architecture  under  Copernicus. 

2.1.4  Copernicus  Pillars 

For  this  discussion,  the  following  pillars  are  relevant: 

1.  CCC— The  CINC  Command  Center  is  the  shore-based  termination  of  the 
individual  Global  Information  Exchange  Systems  (GLOBIXS)  networks  that 
allows  the  command  center  to  access  information  among  data  fusion  and 
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correlation  centers,  as  well  as  the  technical  information  centers.  A  component 
of  the  CCC  is  the  “Anchor  Desk,”  which  represents  the  users  at  this 
termination.  Users  can  register  their  information  requirements  with  the  Anchor 
Desk  to  ensure  that  this  information  is  captured  and  passed  to  them  over  the 
TADIXS. 

2.  GLOBDCS— These  are  individual  information  networks  established  among  the 
CCC  and  the  various  data  fusion/correlation  centers  and  technical  information 
centers. 

3.  TADIXS— These  are  the  networks  between  the  CCC  and  the  user  TCCs.  They 
are  a  collection  of  bearer  services  that  expedite  the  flow  of  information. 

4.  CSS— This  is  not  a  pillar  of  Copernicus,  but  a  means  to  implement  the  TADIXS 
and  GLOBIXS  pillars  that  allow  information  to  flow  within  the  networks.  A 
portion  of  CSS  (COMPLAN)  allows  TCC  users  to  register  their  information 
requirements  with  the  Anchor  Desk  to  extract  needed  information  from  the 
system.  Another  portion  of  CSS  governs  the  flow  of  information  among  CSS 
and  non-CSS  participants  (e.g.,  Joint/Allied  TCCs),  and  among  TCCs  over 
TADIXS. 

2.1.5  Comparison  of  C2MP/MTACCS  and  Copernicus 

Both  Copernicus  and  the  Command  and  Control  Communications  Master  Plan 
(C2MP),  along  with  its  implementation,  the  Marine  Corps  Tactical  Command  and  Control 
System  (MTACCS),  are  designed  to  provide  flexibility  within  the  volatile  world-political 
environment  that  has  arisen  following  the  breakup  of  the  Soviet  Union.  Both  satisfy  the 
need  to  rapidly  move  information  from  where  it  exists  to  where  it  is  required,  while 
allowing  maximum  flexibility.  MTACCS  is  a  functional  and  mission-area  implementation 
of  the  Command  and  Control  Communications  Master  Plan. 

Both  Copernicus  and  MTACCS  stress  open-systems  interconnection  (OSI) 
architecture,  with  modular  and  reusable  software,  provided  either  as  Commercial  Off  the 
Shelf  (COTS)  or  Government  Off  the  Shelf  (GOTS). 

While  on  the  surface,  the  two  architectures  should  be  compatible,  underlying  factors 
exist  that  must  be  addressed  before  such  an  assessment  can  be  made.  First,  the  emphasis 
of  Copernicus  has  been  to  provide  access  to  shore-based  major  command  centers,  tapping 
into  a  large  amount  of  information  that  has  not  yet  been  effectively  exploited  in  Naval 
Warfare.  This  information  is  then  made  available  to  the  principal  striking  arm  of  the 
Navy,  which  is  the  afloat  Battle  Group  Tactical  Command  Center  (TCC).  Thus  far,  the 
emphasis  has  not  been  extended  below  this  Battle  Group  TCC.  Unfortunately,  this 
connectivity  is  about  one-step  above  where  MTACCS  begins.  The  MTACCS  system 
requires  information  from  some  of  the  GLOBIXS  sources,  through  the  CCC,  but  must 
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also  extend  to  joint  sources,  to  cross-echelon  (e.g.,  Air  Force  Wings  and  Army  Corps), 
and  to  down-echelon  (to  field  units),  in  order  to  perform  its  mission.  Thus  far,  the 
emphasis  in  Copernicus  has  been  with  rather  large  information  systems  and  computing 
systems,  while  the  MTACCS  must  deal  not  only  with  these  large  systems,  but  also  with 
man-portable  devices  operating  in  a  hostile  combat  environment.  Unlike  Copernicus, 
which  focuses  on  information  transfer  from  computer  to  computer  as  the  primary  media, 
the  Marine  Corps,  in  down-  and  cross-echelon  communications,  must  deal  with  a 
significant  percentage  of  information  transfer  by  voice  communications.  A  significant 
percentage  of  up-echelon  communications  for  the  Marine  Corps  will  benefit  from 
evolutionary  development  provided  by  Copernicus.  However,  cross-echelon  and 
down-echelon  communications  will  not  benefit  substantially  from  Copernicus  system 
developments  until  data  systems  assume  a  larger  role  at  tactical  echelons. 

The  proliferation  of  software  subsystems  and  databases  should  cause  concern  for  both 
Copernicus  and  MTACCS.  Previous  experiences  in  subsystem  integration  indicate  that 
close  control  must  be  established  early  in  the  design  stage  of  software  development  to 
ensure  interoperation. 

Another  issue  exists  that  is  a  product  of  implementing  open-systems  architecture  and 
diverse,  somewhat-incompatible  systems  in  the  open  environment.  The  traditional  network 
tends  to  be  hardware  oriented,  stressing  interface  design  specifications  that  describe  the 
physical  connectivity  between  systems.  In  the  open  system,  the  emphasis  should  be  upon 
information,  rather  than  the  specific  harware  interfaces  that  are  simply  pipelines  for 
information.  Copernicus  suggests  “user  pull”  for  getting  information  as  opposed  to  the 
broadcast  (that  tends  to  overload  the  bearer  services  or  results  in  a  user  receiving 
information  who  does  not  require  the  information).  In  order  to  accomplish  a  true  open 
system  with  information  exchange  based  on  access  rules  or  context  registration  with  a 
controller  (Anchor  Desk),  each  piece  of  information  within  the  system  should  be 
considered  to  be  a  separate  object.  This  allows  introduction  of  object-oriented  information 
structures  within  the  system.  These  are  not  object-oriented  databases  or  database- 
management  systems  that  have  not  yet  achieved  full  functionality  and  are  emergent 
technology  that  operates  at  extremely  slow  speeds  today.  Instead,  these  information 
structures  have  considerable  utility  in  information  management  and  in  transitioning 
existing  systems  to  an  open-system  environment.  The  first  utility  gained  by  object-oriented 
information  structures  is  data  integrity.  Each  information  object  has  ownership  that  is  an 
attribute  of  the  information.  One  problem  of  information  use  is  that  the  same  information 
can  arrive  at  a  system  via  separate  paths.  This  could  result  in  “double  counting”  or  in  a 
single  event  resulting  in  more  than  one  track  (a  common  problem  in  data  fusion).  A 
second  utility  is  the  capability  to  use  information  from  existing  systems  without 
an  immediate  requirement  to  transition  the  exsiting  system  to  an  open-system 
environment.  An  applique  or  “data  tap”  is  placed  on  the  existing  system  that  translates 
the  existing  information  into  information  objects  that  are  then  registered  within  the 
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global-information  pool  as  being  available.  This  technique  has  been  used  to  allow  access 
to  information  from  older  systems,  when  cost  or  scheduling  prevents  their  being  rehosted 
on  newer  hardware.  For  the  Marine  Corps,  this  might  be  an  option  for  MS-DOS  based 
logistics-support  software  packages,  ensuring  their  interoperability  with  other  MTACCS 
systems  while  waiting  for  their  recoding. 

The  final  utility  of  an  object-oriented  data  structure  is  its  capability  to  perform 
distributed  processing  and  to  modify— or  customize— information  in  a  flexible  manner. 
Each  information  is  registered  with  the  global  pool  as  a  pointer  to  where  the  information 
exists.  User  systems  are  not  required  to  store  the  information  unless  it  is  needed.  If 
needed,  it  is  copied  from  the  source  into  the  user  system,  where  it  can  be  used  or 
modified  to  fit  the  need  of  the  user.  If  the  information  is  modified,  it  is  “owned”  by  the 
user  systems  with  appropriate  ownership  attributes  set  as  the  new  information  becomes  a 
new  object  in  the  global  pool.  User  systems  will  have  access  (when  access  requirements 
are  met)  to  a  large  amount  of  information  without  having  to  store  the  information. 
Information  accounting  is  accomplished  through  a  pointer  that  indicates  where  the 
information  exists,  and  access/recovery  of  the  information  is  accomplished  transparently 
to  the  user  or  user  system.  The  modification  capability,  inherent  in  object-oriented 
software  languages,  allows  users  to  combine  objects  into  single,  complex  objects  or  to 
redefine  the  object  attributes  according  to  their  need.  An  example  of  this  would  be  a 
simple  tracking  problem.  Each  detection  or  observation  of  a  target  becomes  an  object. 
These  objects  can  also  be  combined,  through  fusion/correlation/association,  to  form  a 
single  object  that  is  a  track.  Each  observation  object  that  forms  the  track  is  uniquely 
named.  If  later  it  is  observed  that  an  observation  does  not  fit  with  the  composite  track 
object,  it  can  be  easily  removed  from  the  track  and  reassigned.  This  is  an  improvement 
over  relational  structures  in  which  individual  observations  tend  to  become  lost  when 
combined  to  form  a  track.  Another  improvement  enables  the  user  or  user  system  to 
redefine  the  attributes  associated  with  an  object.  This  is  not  easily  accomplished  under  a 
relational  structure  but  is  inherent  in  the  object-oriented  structure. 

In  order  to  implement  these  utilities,  a  transition  is  needed  to  an  object-oriented  data 
structure.  To  make  this  transition  requires  formulating  an  information  dictionary  that 
describes  what  the  information  looks  like.  While  this  seems  like  a  considerable  task,  it  is 
nothing  more  than  good  software  engineering  that  allows  information  interoperability. 
Development  of  the  information  dictionary  will  be  essential  for  transition  to  an  open- 
systems  environment,  both  for  MTACCS  and  Copernicus. 

Other  fundamental  differences  exist  between  Copernicus  and  MTACCS  that  relate 
specifically  to  system  specifications  and  implementation  of  the  two  architectures.  These 
will  be  discussed  as  issues  in  the  remainder  of  this  study. 
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Both  MTACCS  and  Copernicus  contain  event-driven  networks,  requiring  a  definite 
response  time  for  the  user,  contingent  on  the  tactical  scenario.  This  point  will  be  critical 
in  addressing  bearer-service  bandwidth  and  information-transfer  considerations. 

2.2  TASK  ANALYSIS/ISSUES  IDENTIFIED 

2.2.1  GLOBIX  Sources/Information 

Figure  2-3  depicts  the  GLOBDCS-to-MAGTF-TCC  connectivity,  over  TADIXS,  and 
uses  the  CCC  Anchor  Desk  to  control  the  two-way  flow  of  information. 


Figure  2-3.  CINC  Command  Center  and  MAGTF- 
TCC  connectivity. 


The  description  of  the  individual  GLOBDCS  indicates  the  nature  of  information  that 
would  reside  in  the  network. 

The  preliminary  documentation  for  the  Communications  Support  System  (CSS)  and 
the  Copernicus  Implementation  Plan  demonstrates  how  the  information  transfer  will 
occur,  from  the  MAGTF-TCC  perspective.  The  MAGTF  TCC,  through  the 
communications  planning  (COMPLAN)  software  of  CSS,  will  register  the  context  of  the 
desired  information  with  the  CCC  Anchor  Desk.  The  MAGTF-TCC  personnel  can  specify 
the  nature  of  information  that  is  of  interest  to  them,  resulting  in  transfer  of  only  desirable 
information.  One  of  the  premises  of  the  Copernicus  architecture  is  that  it  is  user  driven, 
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rather  than  being  origiiiator  driven.  As  an  example,  MAGTF-TCC  personnel  could 
indicate,  through  the  COMPLAN,  that  they  want  to  see  intelligence  and  weather 
information  relevant  to  a  particular,  operator-bounded,  geographic  area;  and  as  a  result  of 
this  registration,  they  would  only  see  the  requested  information. 

Another  significant  issue  relating  to  the  GLOBIXS  network  involves  “what” 
information  is  to  be  passed  from  the  MAGTF  TCC  to  the  GLOBIXS.  Part  of  the 
Copernicus  and  open-system  architecture  allows  access  to  information  residing  within  the 
system,  so  long  as  access  criteria  are  met.  The  primary  source  of  tactical  information  that 
would  interest  the  GLOBIXS  would  be  the  Commander’s  Situation  Report  (SITREP). 

The  nature  of  information  exchanged  indicates  how  well  the  aggregate  system  will 
operate  under  stress.  The  GLOBIXS  participants  comprise  shore-based  facilities 
connected  by  high-speed  bearer  services  that  enable  rapid  information  exchange. 
Sometimes  this  information  is  in  the  form  of  Binary  Large  Objects  (BLOBS),  which  could 
be  large  databases,  maps,  or  detailed  graphics.  Even  without  the  transfer  overhead  caused 
by  the  standardized  protocol  or  packetizing  technique,  the  time  required  to  transfer  these 
BLOBS  is  not  insignificant.  As  an  example,  consider  the  case  of  an  average  graphics  file 
(about  1.5  MB).  The  capacity  of  a  normal  T1  line— which  allows  the  current  state  of  the 
art  transfer  bandwidth— is  1.544  Mbps.  This  will  take  about  8  seconds  for  transfer, 
ignoring  overhead  and  loading.  The  problem  arises  when  this  1.5*MB  file  is  placed  on 
lower  bandwidth  bearer  services,  comprising  the  TADIXS.  At  a  2400-bps  transfer  rate, 
the  same  1.5-MB  file  will  take  approximately  5000  seconds  (83  minutes),  again  ignoring 
transfer  overhead.  While  the  high-bandwidth  GLOBIXS  will  be  able  to  handle  transfers  of 
this  order,  the  lowest  capacity  TADIXS  bearer  services  will  quickly  become  clogged  under 
this  loading.  The  first  step  for  assessing  sufficiency  of  the  Copernicus  network  lies  in 
identifying  the  information  residing  in  the  GLOBIXS  that  is  of  interest  to  the  MAGTF 
TCC. 

2.2.2  TADIXS  Issues 

One  of  the  issues  concerning  the  TADIXS  has  already  been  discussed  under 
GLOBIXS.  In  addition  to  identifying  the  information  to  be  exchanged  with  GLOBIXS,  a 
similar  approach  must  be  taken  for  TCC-to-TCC  communications  within  TADIXS.  To 
accomplish  this,  we  must  identify  the  current  requirements  for  TADIXS  participants  from 
the  MAGTF-TCC  perspective.  What  are  the  Joint  and  Allied  components  of  the  Navy, 
Army,  Air  Force,  and  Coast  Guard  that  must  reside  on  the  TADIXS?  Once  the 
participants  and  nature  of  information  are  identified,  the  next  step  is  to  define  the 
TADIXS  in  terms  of  current-bearer  services  (and  eventually  future-bearer  services). 

A  distinction  must  be  made  between  TADIXS,  which  supports  up-echelon  or  TCC-to- 
TCC  communications,  and  organic  MAGTF  networks,  which  are  not  considered  in  this 
study. 
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When  the  MAGTF  TCC  is  in  a  garrison  state  (ashore  at  a  fixed  site),  establishing 
TADIXS  connectivity  via  high-capacity  (T1  line  or  equivalent)  bearer  services  could  be 
advantageous.  This  might  also  be  a  prudent  strategy  for  developing  a  prototype,  since  it 
would  provide  data  for  evaluating  use  (and  extend  afloat/deployed  requirements),  while 
providing  needed  training  to  Command  Center  operators. 

2.2.3  Afloat  Support  and  Transition  to  Ashore 

Afloat  support  is  covered  in  the  NTCS-A/MTACCS  subtask.  During  transition  from 
the  afloat  environment  to  the  ashore  (deployed)  environment,  afloat  connectivity  should 
probably  not  be  broken  until  ashore  connectivity  is  positively  established.  This  transition 
procedure  is  doctrinal  and  not  included  in  this  study. 

What  will  be  included  in  the  study  are  the  hypothesized  requirements  for  information 
in  both  the  afloat  and  ashore  (deployed)  states.  Most  tactical  functions  in  the  afloat  state 
will  support  planning  and  assessment,  with  some  near  realtime  support  provided  for 
executing  amphibious  assault. 

2.2.4  Organic/Nonorganic  Bearer  Services 

Nonorganic-bearer  services  include  only  those  that  are  external  to  the  MAGTF.  These 
are  comprised  primarily  of  Copemicus-TADDCS  bearer  services.  Organic-bearer  services 
include  those  networks,  designated  within  MCTCA-Midterm,  that  provide  intra-MAGTF 
communications  services.  These  organic-bearer  services  include  some  communications 
channels  and  networks  that  would  be  classified  as  Joint  or  multiservice  channels  or 
networks.  An  example  of  this  would  be  an  air-coordination  network,  on  which  Marine 
Corps  aircraft  and  ground  controllers  could  reside,  but  that  also  might  be  used  for 
controlling  Navy,  Air  Force,  or  Army  aircraft. 

Organic-bearer  services  are  not  addressed  in  this  study,  although  the  impact  of  CSS 
implementation  on  organic-bearer  services,  and  potential  gains  of  implementation  should 
be  assessed. 

2.2.5  Prioritization  of  Voice-Media  Communications 

MAGTF/MTACCS  long-term  plans  call  for  reducing  the  percentage  of  voice-media 
communications  to  a  level  of  about  10  percent  of  total  communications.  Review  of 
nonorganic  circuits  indicates  that  a  significant  portion  of  communications  is  conducted 
using  other  than  voice  media,  and  that  reduction  of  levels  to  about  10  percent  should  be 
attainable.  The  same  statement  cannot  be  made  for  organic  voice-media  communications. 
Review  of  organic-communications  channels  and  usages  indicates  that  a  significant 
percentage  of  intra-MAGTF  communications  is  accomplished  using  voice  media.  If  a 
decision  is  made  to  implement  CSS  for  intra-MAGTF  communications  to  exploit  some  of 
the  queuing  and  circuit-usage  features  of  CSS,  the  CSS  development  team  should  assess 
the  impact  of  placing  a  low  priority  on  voice-media  communications  capabilities. 
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2.2.6  Standards 


Review  of  Marine  Corps  and  Copernicus  system-development  standards  and 
architectural  design  standards  show  that  the  Marine  Corps  provides  far  more  rigorous 
direction  and  guidance,  while  the  Copernicus  and  NTCS-A  standards  tend  to  be  less 
rigorous  under  the  guise  of  evolutionary  development.  Two  possible  courses  of  action  are 
suggested: 

1.  Continue  MTACCS  development  while  monitoring  evolving  Navy-directed 
standards  and  concentrating  on  the  principal  interface  (TADIXS/NTCS-A)  with 
the  Copernicus  system— and  react  to  evolving  standards. 

2.  Take  a  more  active  role  in  selecting  Navy  standards  for  Copernicus  and 
NTCS-A. 


2.3  OPTIONS/RECOMMENDATIONS 

Copernicus  will  become  the  de  facto  standard  for  Navy  Communications,  Command 
and  Control,  Computing,  and  Intelligence  (C4I). 

Copernicus  is  an  evolutionary  architecture,  which,  in  the  future,  could  potentially 
provide  enhanced  capabilities  for  the  Marine  Corps.  Of  particular  importance  to  the 
Marine  Corps  should  be  (1)  the  improved  bandwidth  of  the  TADIXS,  (2)  the  capability  of 
the  command  center  to  quickly  transfer  information  from  the  GLOBIXS,  and  (3)  the 
scheduling/resource  sharing  and  interoperability  guarantees  of  CSS.  Unfortunately,  the 
thrust  of  the  CSS  is  toward  the  afloat  command  center,  rather  than  the  mobile  ashore 
command  center— which  could  cause  some  hardware  difficulties  for  the  Marine  Corps. 

Copernicus  could  also  solve  some  questions  about  MAGTF  Master-Plan  priority 
capabilities  by  establishing  connectivity  with  GLOBIXS  subscribers  and  through  potential 
bandwidth  improvements  that  would  come  from  TADIXS  development.  This  could 
particularly  benefit  Marine  Corps  users  of  large-volume  databases  (such  as  logistics). 

To  transition  to  the  open-systems  environment  and  to  implement  user-pull  and 
distributed-information  processing,  the  Marine  Corps  should  begin  transitioning  to  an 
object-oriented  information  structure.  The  first  step  of  this  transition  will  be  to  develop  an 
information  dictionary. 

An  option  for  transitioning  MS-DOS  based  logistics-support  systems  to  the  open- 
system  environment  is  to  place  a  passive  tap  applique  within  the  logistics-support  system 
that  translates  information  to  object-oriented  information.  Recoding  and  rehosting 
software  is  an  expensive  proposition  that  sometimes  results  in  providing  a  lesser 
capability  than  exists  with  the  current  system.  Often  this  is  a  fix  to  something  that  is  not 
really  broken.  The  information  taps,  placed  on  top  of  the  existing  system,  further  provide 
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short-term  interoperability  between  POSIX  and  MS-DOS  based  systems,  allowing  the 
Marine  Corps  to  spend  code-conversion  money  where  and  when  they  want  to. 

Issue  One— The  first  issue  identified  relates  to  the  physical  MAGTF  TCC  to  the  CE 
only.  Each  of  the  MAGTF  components  accomplishes  a  considerable  amount  of  external 
communications.  The  options  are  to  retain  the  definition  of  the  MAGTF  TCC  as  the  CE 
only  and  route  all  external  communications  through  the  CE,  or  to  redefine  the  MAGTF 
TCC  as  embracing  the  CE  and  all  other  component  elements  (CE,  ACE,  GCE,  and 
CSSE).  The  thought  here  is  that  constraining  the  definition  of  the  MAGTF  TCC  to  only 
the  CE  will  result  in  cost  savings;  i.e.,  only  having  to  make  one  component  compatible 
with  Copernicus,  instead  of  four. 

Conversations  with  CSS  program  developers  indicate  that  each  of  the  four  MAGTF 
components  will  require  CSS  equipment  to  be  compatible,  regardless  of  the  routing 
scheme.  At  least  at  this  point  in  the  development,  constraining  the  definition  of  the 
physical  TCC  to  the  MAGTF  CE  will  not  result  in  any  cost  savings  and  might  create  a 
bottleneck  for  communications.  Redefining  the  physical  TCC  to  incorporate  all  MAGTF 
components  might  allow  each  of  the  components  direct  access  to  TADIXS,  thus  relieving 
the  potential  bottleneck. 

We  recommend  expanding  the  physical  TCC  boundaries  to  include  all  MAGTF 
components,  with  each  one  allowed  direct  access  to  TADIXS. 

Issue  Two— The  second  issue  relates  to  proliferation  of  software  and  databases,  both 
in  Copernicus  and  MTACCS.  While  some  of  these  problems  can  be  corrected  through 
configuration  management,  some  consistent  and  concrete  plan  must  be  adopted  that 
addresses  how  these  component  software  and  databases  fit  together  in  the  context  of  the 
MAGTF  mission.  This  is  normally  accomplished  through  a  Concept  of  Operations.  In  our 
research,  we  could  find  nothing  that  approximates  a  Concept  of  Operations  for  the 
MAGTF  TCC.  (This  does  not  mean  that  such  a  document  does  not  exist,  but  rather  that 
we  did  not  find  it  in  our  investigation.)  Such  a  document  would  be  helpful  for  system 
designers  and  integrators,  since  it  would  describe  how  each  of  the  individual  components 
will  fit  together  in  an  operational  context.  We  recommend  that  such  a  document  be 
prepared.  A  sample  Concept  of  Operations/Standard  Operating  Procedures  is  included  in 
the  GLOBIXS  B  Early  Implementation  Concept  of  Operations/Standard  Operating 
Procedures,  dated  10  June  1992.  A  portion  of  this  Concept  of  Operations/Standard 
Operating  Procedures  document  should  focus  on  developing  an  information  dictionary 
that  defines  information  used  and  generated  by  MTACCS  systems.  This  will  assist  in 
transitioning  to  an  object-oriented  open-system  environment. 

Another  portion  of  the  issue  relates  to  creating  an  object-oriented  information 
structure  for  existing  and  developmental  MTACCS  systems,  and  options  for  transitioning 
from  what  exists,  today,  to  the  future  open-systems  environment.  The  first  option  would 
be  to  expedite  recoding  all  existing  MTACCS  systems.  The  second  option  would  be  to 
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invoke  an  applique  that  would  translate  the  existing  system’s  information  so  it  can  reside 
in  an  object-oriented  structure.  We  recommend  the  second  option,  because  it  allows  the 
Marine  Corps  to  retain  all  available  information,  while  also  allowing  a  more  relaxed  rate 
of  recoding.  In  addition,  this  option  does  not  fix  something  that  is  not  broken. 

We  do  not  recommend  immediate  transition  to  an  object-oriented  data-management 
system  (OODMS).  Available  OODMS  do  not  perform  well  enough  to  provide  near 
realtime  operation  in  event-driven  networks  requiring  a  guaranteed  response  time  for  the 
user.  Object-oriented  languages  (such  as  C++)  and  existing  relational  database- 
management  systems  have  performed  adequately  to  operate  within  the  event-driven 
network  environment  and  should  suffice  until  OODMS  technology  evolves  into  a 
responsive  alternative.  When  this  occurs,  transitioning  to  an  OODMS  would  be 
advantageous,  simply  because  it  provides  a  more  flexible  option  to  users  and  user 
systems.  OODMS  must  be  monitored  as  an  emergent  technology  that  could  be  used  with 
MTACCS  and  Copernicus. 

Issue  Three— This  issue  relates  to  physically  controlling  information  flow  from  the 
GLOBIXS,  via  the  TADIXS,  to  the  MAGTF  TCC.  The  concern  here  is  that  Marine  Corps 
requirements  for  information  from  the  GLOBIXS  source  are  adequately  represented  at  the 
Anchor  Desk.  In  the  description  of  the  Copernicus  architecture,  this  is  accomplished 
through  the  COMPLAN,  that  indicates  the  specific  information  the  user  wants  to  see. 
Current  development  of  Copernicus  emphasizes  afloat  concerns.  We  must  be  cautious  to 
ensure  that  ashore  concerns  of  the  MAGTF  TCC  are  represented  in  the  development. 

We  recommend  close  coordination  with  Copernicus  and  CSS  system  designers  and 
engineers  to  ensure  that  MAGTF-TCC  information  requirements  are  met  and  that 
sufficient  mechanisms  are  in  place  to  ensure  the  expeditious  flow  of  required  information 
from  CCC-GLOBIXS  sources  to  the  MAGTF-TCC  users. 

Additional  recommendations  are  made  within  paragraph  2.4  concerning  an 
opportunity  for  developing  a  MAGTF-TCC  prototype. 

Issue  Four— This  issue  relates  specifically  to  the  physical  capabilities  of  GLOBIXS  and 
TADIXS  as  information-transfer  pipelines.  This  is  in  response  to  the  attitude  that 
eventually  sufficient  bandwidth  will  exist  within  the  system  to  handle  all  of  the 
requirements.  To  ensure  that  sufficient  bandwidth  will  be  available,  we  must  first  identify, 
specifically,  the  current  (and  to  some  degree  the  future)  requirements  for  information 
transfer.  The  first  step  is  to  identify  the  size,  content,  and  format  of  information  that  the 
MAGTF  TCC  will  extract  and  input  to  the  system  over  the  TADIXS.  We  must  then 
determine  transfer  rates  of  existing  bearer  services  to  estimate  the  timeliness  of 
information.  This  must  reflect  the  stress  factor  of  a  combat  environment.  When  this  is 
accomplished,  we  can  determine  the  required  bandwidth  and  compare  this  with  existing 
bandwidth  to  ensure  that  Copernicus  will  provide  sufficient  capability  to  perform  the 
MAGTF  mission. 
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Some  of  the  information  needed  will  be  gathered  in  this  initial  study.  Additional  effort 
should  be  taken  to  finish  this  portion. 

Several  of  these  issues  can  be  resolved  by  developing  a  MAGTF-TCC  prototype  and 
by  connecting  the  TCC  to  a  CCC  and  other  TCCs.  The  details  of  developing  such  a 
prototype  are  contained  in  paragraph  2.4  that  appears  after  the  issues  and 
recommendations  synopsized  in  the  following  matrices. 

ISSUE/RECOMMENDATION  MATRIX 

NARRATIVE 
MAGTF.TCC  Definition 

Two  Proliferation  of  software  and  Develop  a  Concept  of  Operations  to 

databases  define  how  all  components  fit 

together. 

Centrally  control  development  of  sub¬ 
systems  starting  at  the  design  phase. 

Centrally  control  databases  and 
ensure  sufficient,  detailed  documenta¬ 
tion  to  ensure  information  con¬ 
sistency. 

Validate  replication  among  databases. 
Begin  migration  to  object-oriented 
information  structure  (information 
dictionary). 

Investigate  object-oriented  “data- 
tap”  appliques  as  an  alternative  to 
recoding  existing  systems  that  are 
performing  suitably,  but  that  are 
not  in  the  UNIX/POSIX  operating 
environment,  or  that  have  not 
been  converted  to  Ada. 

Monitor  evolution  of  object- 
oriented  data-management  systems. 
When  these  systems  are  sufficiently 
responsive  to  operate  in  an  event- 
driven  environment  with  guaranteed 
response  times  (near  realtime),  con¬ 
vert  from  relational  data-management 
systems  to  OODMS. 


RECOMMENDATION 

Define  the  physical  MAGTF  TCC  as 
encompassing  all  MAGTF  components 
(CE,  GCE,  ACE,  and  CSSE). 


ISSUE 

NUMBER 

One 
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ISSUE/RECOMMENDATION  MATRIX 


ISSUE 

NUMBER 

NARRATIVE 

RECOMMENDATION 

Three 

CCC  Anchor  Desk  to 

Coordinate  closely  with  CSS  and 

MAGTF  TCC 

Copernicus  system  designers  and 
engineers  to  ensure  that 

1.  MAGTF-TCC  information  require¬ 
ments  are  met. 

2.  Sufficient  mechanisms  are  in 
place  to  expedite  flow  of  required 
information  from  CCC-GLOBDCS 
sources  to  MAGTF-TCC  users. 

Four 

Information  transfer 

Define  information  to  be  extracted 
from  GLOBDCS. 

Define  transfer  rate  acceptable  for 
TADIXS  information  transfer  based 
on  mission  requirements.  Assess 
capability  of  existing  bearer  services. 

Prioritization  of  Voice-Media 

If  a  decision  is  made  to  implement 

Communications 

CSS  for  intra-MAGTF  communica¬ 
tions,  push  CSS  development  to 
upgrade  the  priority  of  voice-media 
communications  capabilities. 

Standards 

Continue  development  of  MTACCS 
while  monitoring  evolving  Navy- 
directed  standards,  concentrating  on 
the  principal  interface  (TADDCS/ 
NTCS-A)  with  the  Copernicus  system. 

Development  of  MAGTF- 

As  a  minimum,  provide  representation 

TCC  Prototype 

1 

to  CINCPAC  JT2CM  board  and  C2I 
working  group  to  resolve  many  CCC 
to  MAGTF-TCC  issues  raised  in  this 
study. 

Build  a  prototype  testbed  at  MCTSSA, 
containing  existing  and  develop¬ 
mental  pieces  of  MTACCS  to  support 
an  MEF. 

Site  would  be  deployable  in  a  con¬ 
tingency  (hence,  a  prototype  versus 
a  testbed). 
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ISSUE/RECOMMENDATION  MATRIX 


ISSUE 

NUMBER 

NARRATIVE 

RECOMMENDATION 

Four 

Development  of  MAGTF- 

Establish  connectivity  with  CINCPAC 

TCC  Prototype  (contd) 

CCC  and  JTFC. 

Testbed  portion  of  site  would  support 
both  NTCS-A  and  TADIXS  termina¬ 
tions. 

Design  a  site  for  potential  deploy¬ 
ment,  coordinate  with  operational 
forces  to  ensure  deployability  in  a 
contingency,  but  continue  to  use  as  a 
testbed  to  support  design  and  pro¬ 
curement  decisions. 

Assess  fiscal  impact. 

2.4  DEVELOPMENT  OF  MAGTF-TCC  PROTOTYPE 

The  four  states  of  the  MAGTF  TCC  (Garrison,  Afloat,  Ashore,  and  Transition) 
provide  some  particular  challenges  to  the  designers,  and  some  unique  opportunities  for 
test  and  evaluation.  The  maturity  of  MTACCS,  and  its  documentation,  suggests  that 
perhaps  developing  a  prototype  and  demonstrating  its  capability  would  be  quite  valuable. 
From  experience  in  prototyping  ASW  GLOBDCS  and  ASW  TADIXS,  we  learned  that 
many  of  the  issues  relating  to  interoperability  and  design  can  be  resolved  through 
physically  constructing  a  system.  Marine  Corps  MTACCS-development  plans  and 
Navy/Joint  command-center  development  plans  seem  to  offer  an  opportunity  to  develop  a 
prototype. 

In  the  Atlantic  Fleet,  a  GLOBIXS  network  exists  at  CINCLANTFLT.  Unfortunately, 
this  GLOBIXS  is  an  ASW  GLC  JIXS,  which  is  of  little  concern  to  the  Marine  Corps.  The 
GLOBIXS  has,  however,  tapped  into  a  notional  CCC  at  the  CINCLANTFLT  complex  in 
Norfolk.  The  ASW  GLOBIXS  is  using  CINCLANTFLT-provided  JOTS  information  and  is 
not,  as  yet,  tied  into  the  intelligence  network.  Figure  2-4  is  a  connectivity  representation  of 
the  existing  GLOBIXS  B  and  the  Norfolk  Metropolitan  Area  Network  (MAN),  which  is  a 
candidate  for  MAGTF-TCC  prototype  development. 

As  part  of  the  GLOBIXS  implementation,  the  Norfolk  MAN  was  tied  to  a  new  wide 
area  network  (WAN)  by  means  of  a  router,  indicated  by  a  circle  and  “R”  between  the 
networks.  Conceptually,  all  information  available  to  the  Norfolk  MAN  is  available  on  the 
GLOBDCS-B  WAN  (which  could  include  intelligence  information).  Input  from  the  Fleet 
Numerical  Oceanography  Command  (FNOC)  is  made  at  COMUNDERSEALANT  and 
NAVOCEANPROFAC  through  local  area  networks,  meaning  that  some  environmental 
information  is  available  on  the  GLOBIXS. 
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CINCLANTFLT 


COMSUBLANT 


The  plan  for  establishing  connectivity  would  be  to  connect  with  the  GLOBIXS  WAN, 
as  depicted  in  figure  2-5,  with  the  USMC  MAGTF  TCC  located  at  Quantico.  Connectivity 
and  information  access  would  have  to  be  negotiated  with  CINCLANTFLT  and  CTF-84. 
While  the  depiction  indicates  that  CTF-84  has  an  air-operations  function;  this  is 
specifically  ASW  oriented  and  largely  Maritime  Air  Patrol. 

Many  lessons  have  been  learned  as  a  result  of  developing  this  prototype.  Note  the 
number  of  JOTS  terminals  on  the  network.  These  are  two  separate  releases  of  JOTS,  with 
some  of  the  terminals  functioning  as  file  servers.  Connectivity  with  the  GLOBIXS  would 
be  established  via  bridge/router,  through  a  JOTS,  and  would  approximate  a  TADIXS. 
Establishing  connectivity  through  the  LANTFLT  GLOBIXS  might  have  some  advantages, 
but  these  appear  to  be  outweighed  by  the  disadvantages  of  limited  information  (of  interest 
to  the  Marine  Corps)  availability.  On  the  plus  side,  the  linkages  used  within  the 
LANTFLT  GLOBIXS  B  are  almost  purely  NTCS-A  linkages,  with  the  various  versions  of 
JOTS  used  to  establish  connectivity  among  members. 

We  do  not  recommend  this  option. 
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Figure  2-5.  LANTFLT  USMC  to  GLOBIXS-WAN  connectivity. 


The  second  option  is  provided  by  developmental  efforts  in  the  Pacific  at  CINCPAC. 
The  thrust  of  this  effort  is  to  construct  a  Joint  Command  Center  that  supports  CINCPAC 
and  a  Joint  Task  Force  Commander  (JTFC).  The  effort,  which  CINCPAC  and  DARPA 
support,  will  have  to  bridge  between  Copernicus  and  other  service  C2I  architectures. 
Within  the  Copernicus  world,  project  capabilities  will  include  (1)  Intel  Anchor  Desk, 
(2)  Environmental  Anchor  Desk,  (3)  ASW  Anchor  Desk,  (4)  Strike  Anchor  Desk,  and 
(5)  Amphib/Specops  Anchor  Desk.  Most  of  these  are  of  interest  to  MTACCS  and  their 
establishing  connectivity  with  Copernicus.  Figure  2-6  depicts  the  development  and  joint 
test  and  evaluation  strategy,  and  also  depicts  where  the  Marine  Corps  could  potentially 
fit  in. 

In  concept,  the  effort  would  combine  the  CINCPAC/DARPA-development  effort  with 
the  efforts  of  NRAD  (CSS  prototype  development)  and  MCTSSA  (MTACCS),  as  well  as  a 
broad  range  of  6.2  and  6.3  joint-programs  sponsored  by  the  Marine  Corps.  The  MCTSSA 
site  would  also  provide  a  testbed  for  interoperable  systems  that  are  required  to  survive  in 
NTCS-A,  Copernicus,  and  Joint  worlds. 
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NOTIONAL  USMC  MAGTF-TCC 
PROTOTYPE  DEVELOPMENT 


MCTSSA 


Figure  2-6.  Candidate  PACFLT  USMC  MAGTF-TCC 
prototype  development. 

The  manager  for  the  CINPAC  effort  is  the  Joint  Theater/Task  Force  Crisis 
Management  (JT2CM)  Board  and  their  various  working  groups.  The  purpose  of  the  effort 
is  to  evaluate  the  ability  of  task-force  component  C4I  systems  to  interoperate  between 
themselves  and  with  the  C4I  systems  of  the  Joint  Task  Force  Commander  (JTFC)  and 
rear-echelon  supporting  commands.  This  plan  is  consistent  with  the  long-term  goals  and 
objectives  of  the  Marine  Corps. 

A  relationship  with  JT2CM,  and  particularly  with  the  C2I  working  group,  would  benefit 
the  Marine  Corps  significantly.  First,  the  C2I  working  group  is  beginning  to  address  some 
of  the  issues  raised  in  this  study  relevant  to  CCC-to-MAGTF-TCC  connectivity.  Second, 
the  JT2CM  and  C2I  working  group  is  living  in  the  Joint  world,  which  is  the  domain  in 
which  the  Marine  Corps  must  reside  because  of  its  mission.  Answers  to  issues  that  affect 
the  Joint  world  would  logically  affect  Marine  Corps  operations.  For  these  reasons,  we 
recommend,  as  a  minimum,  that  liaison  be  established  with  the  JT2CM  and  C2I  working 
group.  The  Marine  Corps  brings  to  the  table  a  relatively  mature  C2  system  (MTACCS) 
and  considerable  experience  in  Joint  operations,  as  well  as  a  wealth  of  excellent 
documentation  covering  requirements  and  systems. 

Beyond  this  minimum  level  of  participation,  a  broad  range  of  options  exists  for  the 
Marine  Corps.  A  preferred  option,  along  with  the  basic  liaison,  is  establishing  connectivity 
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with  the  Joint  and  CCC  prototypes  constructed  by  CINCPAC.  The  termination  of  this 
connectivity  would  be  at  MCTSSA,  which  would  be  a  prototype  MAGTF  TCC  simulating 
functions  in  garrison  and  afloat  modes.  The  pipeline  to  the  prototypes  would  be  through 
T1  lines  and  existing  bearer  services,  with  bridge/router  functions  at  MCTSSA.  This 
particular  proposal  would  require  establishing  a  MTACCS  LAN  at  MCTSSA  that  could 
also  support  MTACCS  test  and  evaluation.  The  LAN  would  immediately  assemble  all 
existing  pieces  of  MTACCS  and  would  add  new  pieces  as  they  became  available. 
Prototype  development  would  also  provide  a  testbed  for  hardware  and  software  that  will 
be  required  to  operate  in  a  deployable  Joint  or  Copernicus  environment. 

Figures  2-7  and  2-8  depict  a  hypothesized  connectivity  and  the  functioning  of  such  a 
prototype.  This  includes  a  speculated  functional  arrangement  of  the  facility  at  MCTSSA, 
which  should  be  capable  of  supporting  both  afloat  and  garrison  MAGTF-TCC  states. 

There  is  a  concern  over  establishing  connectivity  between  operational  (CCC)  and  test 
facilities  (MCTSSA  MAGTF  TCC).  This  concern  is  the  reason  for  classifying  the  site  and 
system  for  prototype  development  rather  than  as  a  testbed.  The  site  would  mimic  current 
capabilities,  being  a  collection  of  existing  equipment  and  software  that  supports  an  MEF. 
An  aspect  of  the  effort  that  should  be  enforced  is  that  the  site  could  be  deployed  to 
support  an  operation,  if  required;  and  to  ensure  that  this  is  the  case,  there  should  be 
frequent  interaction  between  MCTSSA  and  operating  forces.  The  site  should  also  be  an 
active  participant  in  FDS  exercises  as  a  baseline  and  evolutionary  C2FAC.  These 
exercises  can  be  augmented  by  command-post  exercises  conducted  at  the  CINC  or  Joint 
level.  While  the  initial  implementation  will  clearly  provide  a  significant  resource  for 
enabling  the  Marine  Corps  to  perform  development  and  test  and  evaluation  to  support 
procurement  decisions,  it  will  also  provide  a  significant  capability  to  field  a  tested  system 
in  response  to  short-fused  requirements.  The  architectural  and  design  philosophy  of  the 
site  should  reflect  this  requirement. 

This  is  the  recommended  option  because  of  (1)  the  obvious  benefits  to  system 
development  and  test  and  evaluation  in  support  of  procurement  decisions  and  (2)  the 
capability  to  deploy  the  site  on  short  notice,  along  with  the  interaction  between  MCTSSA 
and  operating  forces. 

Many  particulars  are  left  to  be  worked  out  for  each  of  the  options.  To  be  specific,  the 
fiscal  aspects  of  each  option  must  be  identified.  The  first  step  required  of  this  preferred 
(connectivity)  option  is  the  step  required  of  the  previous  recommendation,  which  is  to 
establish  an  active  liaison  with  the  JT2CM  and  C2I  working  groups.  This  will  be  the 
vehicle  needed  to  establish  the  connection  and  to  perform  the  negotiations  to  make  it 
happen.  Once  the  connection  is  established,  the  operating  environment  for  Copernicus, 
Joint,  and  NTCS-A  information  networks  will  be  created,  allowing  the  evolutionary 
development  process  to  continue. 
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MAGTF-TCC  PROTOTYPE 


All  MAGTF-TCC  hardware  and  software  (MTACCS)  will  be  the  same  except 
for  the  NTCS-A  interfaces.  The  prototype  will  be  able  to  software  configure  to 
represerrt  all  four  MAGTF-TCC  states. 

Tbe  distinction  among  states  is  repres&ftational  only. 


Figure  2-7.  MAGTF-TCC  connectivity. 


I 

I 


MAGTF-TCC  PROTOTYPE 
PHYSICAL  REPRESENTATION 


Each  MAGTF  component  network  will 
have  one  common  software  set 
(MTACCS),  but  will  represent  both 
Garrision/Ashore  and  AfloaVTransition 
states. 


NTCS-A 
JOTS  ■■ 


CE  NETWORK 


- ^ 

ACE  NETWORK 

- - - 

CSSE  NETWORK 


NTCS-A/JOTS  [or  substitute] 
hardware/software  will  si^port  only 
Afloat/Transition  state  prototype. 

All  other  Internal  hardware  will 
support  all  states.  Prototype 
yrill  be  able  to  configure  as  a 
TCC  supporting  all  states. 


GCE  NETWORK 


Each  component  may  have 
their  own  connectivity  with 
the  TADIXS. 


I  Figure  2-8.  MAGTF-MTACCS  architecture. 
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3.  CSS  TO  SUPPORT  MAGTF-CE  ASHORE 


3.1  TASK  DESCRIPTION 

Investigate  the  feasibility  of  designing  the  MAGTF  CE  ashore  according  to  Copernicus 
principles  to  provide  the  MAGTF-CE  Communications/Electronics  Staff  Section  a  digital 
system  and  technical  control  (SYSCON/TECHCON)  capability. 

3.1.1  Operational  Context  of  Task 

The  purpose  of  the  following  paragraphs  is  to  describe  the  operational  context  of  an 
MEF-size  MAGTF  CE  in  the  field. 

The  commander  of  the  MAGTF  is  designated  by  appropriate  authority,  normally  from 
a  source  outside  the  MAGTF.  The  commander  is  supported  from  a  Command  Ele¬ 
ment  (CE)  made  up  of  personnel  and  material  resources  from  outside  the  other  three 
elements  of  the  MAGTF. 

The  capabilities  of  the  CE  extend  and  complement  the  command  and  control  capabili¬ 
ties  of  the  other  three  elements  of  the  MAGTF.  They  do  not  duplicate  them  under  normal 
circumstances.  Liaison  teams  are  heavily  deployed  to  ensure  coordination  of  all  four  ele¬ 
ments  of  the  MAGTF. 

The  separate  CE  allows  the  other  three  elements  of  the  MAGTF  to  concentrate  their 
C2  efforts  on  commanding  the  respective  element.  The  MAGTF  commander  may  author¬ 
ize  direct  liaison  between  the  other  elements  of  the  MAGTF  with  commands  external  to 
the  MAGTF  for  specific  activities  that  do  not  require  intervention  of  the  MAGTF  CE. 

In  amphibious  operations,  the  MAGTF  CE  serves  concurrently  as  the  Landing  Force 
headquarters. 

3.1. 1.1  Types  of  MAGTF.  MAGTFs  are  self-contained,  combined-arms,  task-organized 
organizations  specifically  tailored  to  their  mission  or  anticipated  mission  assignment. 
There  are  three  basic  MAGTFs:  the  MEF,  the  MEB,  and  the  MEV.  Forward-deployed 
MEUs,  those  with  special  training  and  capabilities,  when  certified  by  higher  Marine  Corps 
authorities,  are  designated  as  MEU(SOC).  Special  purpose  MAGTFs  (SPMAGTF), 
smaller  in  size  than  an  MEU,  are  employed  on  specific  missions,  usually  of  very  limited 
duration.  Additionally,  Marine  task  forces  that  do  not  meet  the  strict  definition  of  a 
MAGTF  will  carry  a  different  designation,  such  as  Battalion  Landing  Team  (BLT)  3/9  or 
their  lineal  or  organizational  designation,  e.g.,  3rd  Battalion,  9th  Marines. 

3.1. 1.2  MEU.  The  MEU  is  a  task  organization,  usually  commanded  by  a  colonel,  that 
can  perform  limited  combat  operations.  A  MEU  is  normally  forward-deployed  to  fulfill 
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specific-afloat  deployment  requirements.  When  committed  to  operations  ashore,  it  is  nor¬ 
mally  commanded  and  supported  from  its  sea  base,  e.g.,  most  of  the  CE  remains  em¬ 
barked.  The  GATE  provides  the  MEU  with  its  entry  into  the  Naval  Telecommunications 
System.  CATE  and  MEU  (CLE)  communications  planning  is  performed  concurrently  and 
in  concert.  Marine  Communications  Detachments,  assigned  as  ship’s  company,  at  least  to 
LHA  and  LHD  type  ships,  are  trained  and  organized  to  provide  comm-elec  support  to  the 
embarked  landing  force  commander  and  his  staff.  MARCOMMDETs  are  augmented  with 
MAGTE  communications  personnel. 

3.1. 1.3  MEB.  The  MEB,  also  task  organized,  is  normally  commanded  by  a  brigadier 
general.  Its  mission  is  also  limited.  MEB  combat  operations  may  be  supported  from  the 
sea  base,  from  facilities  ashore,  or  from  a  combination  of  both.  A  reinforced  communica¬ 
tions  company  from  a  Communications  Battalion,  EME,  support  the  CE.  If  the  MEB  is 
operating  from  the  sea  base,  the  CATE  provides  entry  into  the  Naval  Telecommunications 
System.  If  operating  from  ashore,  CommCo  provides  this  service.  Limited  amphibious 
shipping  and  major  elements  of  combat-support  and  combat-service-support  units  must  be 
allocated  to  forming  an  MEB  CE  (no  longer  a  standing  organization).  Because  of  this, 
current  thinking  is  that,  if  an  MEB  or  MEB-like  MAGTE  is  constituted,  the  CE  will  be 
made  up  of  elements  of  the  standing  MEE  CE  and  designed  as  an  MEE(EWD). 

3.1. 1.4  MEF.  The  MEE,  commanded  by  a  major  or  lieutenant  general,  depending  on  the 
mission  and  size,  is  capable  of  conducting  a  wide  range  of  sustained  operations  ashore. 
Like  the  other  MAGTEs,  the  MEE  is  task  organized  and  its  structure  is  tailored  to  the 
assigned  mission.  Communications  support  for  the  MEE  CE  requires  the  full  capabilities 
of  a  CommBn  EME,  augmented  with  communications  assets  from  joint  resources  such  as 
the  JCSE. 

A  MEE-size  MAGTE  CE  and  its  field  command  post  will  require  the  full  capability  of 
a  force  Communications  Battalion,  that  is,  a  CommBn  EME.  These  resources  will  enable 
MEE-intemal  communication  with  the  GCE  (at  least  one  MarDiv),  the  ACE  (at  least  one 
Marine  Aircraft  Wing  (MAW)),  and  the  CSSE  (a  ESSG),  each  of  which  will  have  estab¬ 
lished  a  separately  located  command  post  (CP).  The  COMMBN  EME  also  provides  the 
communications  that  are  operated  within  the  physical  confines  of  the  MEE  CP,  itself, 
where  the  MAGTE  CE  is  located.  The  MEF  G-6  (CEO)  must  also  plan  for  external  com¬ 
munications  with  the  CITE;  the  Marine  Component  Commander  of  a  JTE,  if  one  is  desig¬ 
nated;  adjacent  commands  of  the  same  echelon;  and  the  amphibious  task  force,  if  one  is 
present.  (Note:  If  the  MEE  is  embarked,  the  CATE  is  responsible  for  external  communica¬ 
tions  services  for  the  MEE.) 

The  following  communications  resources  are  used  to  provide  MEF  internal  communi¬ 
cations  and  external  communications. 


3-2 


1.  Radio.  This  term  refers  to  all  wireless  communications  assets,  such  as  single¬ 
channel  voice,  radio  telegraph,  RATT,  and  multichannel. 

2.  Wire/cable.  Wire  and  cable  systems  are  used  to  interconnect  activities  in  close 
proximity  to  each  other.  The  systems  use  field  wire,  fiber  optics,  cable  (multi¬ 
ple  pair),  and  telephones  and  switchboards  for  person-to-person  communica¬ 
tions;  and  interconnections  for  Teletypewriters,  Teletype  switches,  End-User 
Computing  Equipment  (EUCE),  such  as  the  ANAJGC-83  and  AN/UGC-85,  and 
related  switching  systems. 

3.  Radio  Wire  Integration.  This  is  the  interconnection  of  radios  to  switchboards  to 
enable  telephone  subscribers  to  send  messages  over  mobile-radio  circuits. 

4.  Multichannel.  Multichannel  radio  systems  extend  the  wirelines  by  providing 
multiplexed  transmission  paths  via  point-to-point  microwave  relay  paths  over 
areas  where  it  is  not  practical  to  lay  wire. 

5.  Satellite  Communications.  These  provide  for  worldwide  voice  and  data  commu¬ 
nications  for  forces  in  the  field.  The  Marine  Corps  uses  UHF  FLTSAT/ 
LEASAT  and  SHF  systems  that  are  part  of  the  GMF  system  that  accesses 
DSCS.  These  systems  provide  for  entry  into  AUTODIN,  WWMCCS,  and  other 
national  communications  systems. 

6.  Visual,  Sound,  Mail,  and  Courier.  These  resources  supplement  and  comple¬ 
ment  the  assets  just  discussed. 

The  CP  of  an  MEF-size  MAGTF  CE  that  is  planning  to  remain  in  the  field  for  some 
time  is  in  reality  a  small  city  that  could  be  spread  over  1  or  2  square  kilometers  or  more. 
It  has  an  external  security  force  to  protect  against  physical  attack,  internal  security  forces 
to  control  access  to  sensitive  parts  of  the  CP,  berthing  areas,  sanitary  facilities,  messing 
facilities,  and  transportation  and  supply  facilities  needed  for  efficient  operation  of  the 
command,  control,  and  communications  activities  of  the  command.  Central  to  the  C3 
functions  of  the  CP  is  the  Combat  Operations  Center  (COC),  in  which  representatives  of 
the  principal  staff  sections  (Operations  and  Intelligence)  exercise  control  over  current 
operations  of  the  forces  in  the  field.  (Other  services  and  joint  commands  call  their  COC- 
like  facilities  the  Tactical  Operations  Center  (TOC)  or  the  Command  Center  (CC).)  The 
COC  for  an  MEF-size  MAGTF  CE  is  fairly  large,  especially  when  it  accommodates  the 
Fire  Support  Coordination  Center  (FSCC)  liaison  officers  from  adjacent  and  supporting 
units— and  some  communicators  who  operate  selected  tactical  and  command  radio  nets. 
The  COC  could  be  located  in  a  group  of  interconnected  tents,  in  a  large  bunker,  or  in  a 
building  that  may  be  commandeered  for  the  purpose.  The  communications  facilities  to 
support  the  entire  CP  surround  the  COC  and  the  area  in  which  the  MEF  staff  sections 
operate. 
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Command  posts  are  normally  organized  into  echelons  to  effectively  control  the  force. 
All  command  posts  displace  periodically  and  this  displacement  must  take  place  in  an 
orderly  fashion  so  that  control  by  the  commander  and  his  staff  is  not  intemiped. 

The  Main  CP  is  the  principal  headquarters  and  C2  element  of  the  commander  and  his 
supporting  staff.  It  has  the  facilities,  equipment,  personnel,  and  communications  needed 
to  fully  control  and  support  the  force.  The  Main  CP  is  where  future  operations  are 
planned  and,  unless  a  Forward  CP  is  established,  where  current  operations  are  monitored 
and  controlled.  The  Combat  Operations  Center,  responsible  for  controlling  current  opera¬ 
tions,  is  located  in  this  CP  complex. 

The  Forward  CP,  if  established,  is  concerned  with  current  operations  and  their  control. 
Sometimes,  particularly  in  the  case  of  battalion-size  units,  this  CP  echelon  is  called  a 
“Tactical  CP.”  In  the  small-unit  (battalion  or  company)  vernacular,  it  is  also  known  as  a 
“Jump  CP”  or  “Hip-Pocket  CP,”  because  operations  are  run  literally  from  the  map  in  the 
hip  pocket  of  the  commander  or  his  operations  officer. 

The  Rear  CP  contains  such  headquarters  functions  as  administration  and  logistics  that 
should  not  be  conducted  in  the  Main  CP.  As  its  name  implies,  it  is  located  well  to  the  rear 
in  the  area  of  operations.  It  is  far  less  mobile  and  displaces  far  less  frequently  than  the 
Main  CP  or  Forward  CP,  if  established. 

3.1.2  Baseline  MAGTF-CE  Configuration 

The  Marine  Corps,  under  the  direction  of  the  Program  Managers  for  Marine  Air 
Ground  Task  Force  (MAGTF)  Command  and  Control  Systems  (PM,  MAGTF  C2),  is 
developing  a  Marine  Corps  Tactical  Automated  Command  and  Control  System 
(MTACCS).  The  MTACCS  will  enable  desired  information  from  individual  systems  to  be 
combined  into  an  integrated  system.  Interoperability  among  automated  systems  will  be 
achieved  by  utilizing  a  common  family  of  data-processing  hardware,  a  common  operating 
system  and  software,  and  coordinated  functional  applications  software.  All  of  the  systems 
will  implement  either  Marine  Tactical  Systems  (MTS)  broadcast  protocol  or  MTS 
switched  protocol  standards. 

The  primary  programatic  goal  of  CSS  is  to  meet  the  operational  goals  first  through 
integration  of  existing  basic-communications  capabilities;  and  secondly,  through  newly 
developed  capabilities.  Consequently,  the  CSS  architecture  will  follow  the  principles  of 
open-system  design  and  evolutionary  development.  These  are  important  considerations  in 
developing  the  architecture.  This  implies  a  hybrid  approach— a  mix  of  new  modem  design 
and  existing  “stand-alone”  designs— that  is  fully  backward  interoperable;  that  allows  inter¬ 
operability  with  non-CSS,  joint,  and  allied  systems;  that  is  expandable  to  include  emerg¬ 
ing  new  requirements  over  time;  and,  most  of  all,  that  is  affordable. 
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From  a  joint-operations  point-of-view,  Navy/Marine  Corps  tactical  systems  should 
interoperate  and  intercommunicate  during  amphibious  operations  (transition  of  command 
responsibilities)  and  to  a  lesser  extent  during  ashore  operations.  Therefore,  there  is  a 
need  to  demonstrate  the  capability  for  Marine  Corps  users  of  MTACCS  operating  afloat 
to  use  CSS/SCE  communications  assets  during  an  amphibious  assault  and  follow-on 
operations  ashore.  CSS  provides  communications  services  in  the  Navy,  joint,  and  allied- 
tactical  environment.  Communications  services  are  only  part  of  the  command  and  control, 
communications,  computer,  and  intelligence  (C4I)  capability  needed.  CSS  communica¬ 
tions  services  must  fit  within  an  open-system  environment  of  other  joint-  and  allied- 
communications  services,  and  within  an  open-system  environment  of  application  pro¬ 
grams,  information  architectures,  and  hardware  and  software. 

3.1.3  CSS/SCE  SPECIFICATION 

The  CSS  is  a  communications  architecture  that  enhances  battle-force  communications 
connectivity,  flexibility,  and  survivability  through  multimedia  access  and  media  sharing. 
The  CSS  permits  users  to  share  total  network  capacity  on  a  priority-demand  basis  accord¬ 
ing  to  a  predefined  communications  plan.  Automated  network  monitoring  and  manage¬ 
ment  capabilities  are  also  provided  by  the  CSS  to  assist  operators  in  realtime  allocation  of 
communications  resources. 

CSS  must  define  its  own  information  architecture  for  interplatform  coordination  of 
CSS  communication  services.  This  will  be  done  in  the  CSS  Level  “A”  Specification,  and 
implementing  programs  will  design  specific  information  architectures  for  their  require¬ 
ments  within  the  architecture  and  top-level  design  of  the  Level  “A”  Specification.  CSS 
imposes  minimum  architecture  restraints  on  implementing  program  managers  to  permit 
maximum  flexibility  in  responding  to  program  requirements  within  the  open-system  envi¬ 
ronment.  When  CSS  has  imposed  “building  codes,”  it  was  because  they  were  considered 
necessary  for  attaining  CSS  operational  and  programmatic  goals. 

The  Standard  Communications  Environment  (SCE)  is  an  implementation  of  CSS  con¬ 
cepts.  The  SCE  includes  Initialization  and  Recovery,  System  Control,  Communications 
Services,  Subscriber  Security,  Subscriber  Management,  and  Resource  Management. 

The  CSS  communications  architecture  is  designed  for  a  naval  battle  group.  This  archi¬ 
tecture  will  allow  multiple  shipboard  users  to  communicate  among  themselves  using  a 
variety  of  communications  resources.  To  accomplish  this  dynamic  allocation,  a  modular 
design  is  incorporated  in  the  design  of  the  CSS  Standard  Communications  Environment. 

Naval  warfare  inherently  gives  commanders  maximum  latitude.  The  separation  of 
platforms  and  multimission  nature  of  most  platforms  require  that  commanders  act  with  a 
high  degree  of  initiative.  The  distributed  architecture  of  CSS  network  management 
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supports  this  requirement.  Interplatform  management  functions  of  the  System  and  Site- 
Control  Segment  provide  coordination  among  multiple  CSS  (and  disadvantaged  or 
non-CSS)  platforms. 

The  CSS/SCE  modular  design  with  standard  interfaces  allows  technological  improve¬ 
ments  to  be  incorporated  into  specific  areas  of  the  system  without  redesigning  the  whole 
system.  For  example,  new  COTS  modems  with  standard  CSS  interfaces  can  easily  be 
added  to  an  existing  CSS  system.  The  SCE  is  modular  and  constructed  using  open-system 
components.  Major  open  systems  components  include  VME,  680X0,  SPARC,  UNIX, 
Motif,  and  TCP/IP. 

In  addition,  development  and  integration  of  new  and  existing  subscriber  and  radio¬ 
communications  resources  into  the  CSS/SCE  is  simplified  by  the  modular  architecture 
and  adherence  to  open-systems  principles.  Integration  of  a  new  subscriber  requires  only 
developing  a  Subscriber  Interface  Controller  (SIC)  interface  and  incorporating  that  sub¬ 
scriber  into  the  Connection  Plan.  Integration  of  a  new  radio  communications  resource 
requires  only  developing  a  Subnet  Access  Controller  (SAC)  and  incorporating  that  com¬ 
munications  resource  into  the  Connection  Plan. 

NECC,  TACINTEL II,  and  SHF  DCS  are  the  first  three  systems  slated  for  incorporation 
into  the  CSS  architecture.  A  modified  CSS  software  package  allows  NAVMACS  n  to 
operate  with  some  CSS  functionality. 

CSS  is  described  in  the  Communications  Support  System  (CSS)  Overview,  26  July 
1990,  CSS-10001-01.  A  more  thorough  explanation  of  the  CSS/SCE  is  available  in  the 
Communications  Support  System  (CSS)/Standard  Communications  Environment  (SCE) 
Prototype  Description,  6  May  1992,  CSSSCE-RDT-BASE-U-BIVI-ROCO.  Several  acro¬ 
nyms  are  often  used  in  describing  CSS.  These  acronyms,  with  definitions,  are  included  in 
Appendix  C. 

3.1.4  CSS  Functional  Description 

CSS  provides  the  Navy  with  a  communications  service  that  is  responsive  to  user  needs, 
survivable  against  electronic  warfare  and  physical  attacks,  and  efficiently  uses  available 
communications  channel  capacity.  CSS  provides  a  set  of  automated  mechanisms  that 
provides  communications  resource  sharing  and  multimedia  access  for  CSS  subscribers. 

The  CSS/SCE  includes  Initialization  and  Recovery,  System  Control,  Communications 
Services,  Subscriber  Security,  Subscriber  Management,  and  Resource  Management. 

This  paragraph  describes  flow  of  data  through  the  CSS/SCE.  The  Subscriber  Interface 
Controller  (SIC)  provides  access  to  the  CSS/SCE  for  Tactical  Data  Processor  (TDP) 
subscribers.  TDP  subscriber  data  is  encrypted  on  its  way  to  the  SIC.  Control  information 
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is  wrapped  around  the  crypto  and  passed  unencrypted  to  the  SIC.  A  packet  is  formed 
containing  the  encrypted  data  and  the  unencrypted  control  information.  Within  the  SCE, 
the  packet  is  sent  to  the  appropriate  Resource  Access  Controller  (RAC)  according  to  the 
predefined  rules  established  in  the  Connection  Plan.  The  Connection  Plan  is  installed  and 
tailored  in  the  Communications  Plan  Generator/Security  Manager  (CPG/SM).  The  packet 
is  queued  in  the  RAC  until  the  appropriate  SAC  can  process  it  and  ultimately  send  it  out 
over  one  of  the  Link  Access  Radio  Group  (LARG)  components.  Figure  3-1  is  a  function 
diagram  of  the  CSS  SCE. 
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SYSTEM 
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Figure  3-1.  Communications  Support  System  (CSS) /Standard 
Communications  Environment  (SCE). 


3.2  POTENTIAL  ARCHITECTURAL  DESIGNS 


The  current  implementation  of  the  CSS/SCE  is  designed  for  a  Navy  shipboard  commu¬ 
nications  system.  Figure  3-2  illustrates  this  architecture  for  a  CSS  MAGTF-CE  LAN. 
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Must  be  desli^ied  and  lirplemented  by  ktortne  Coips 


Figure  3-2.  CSS  MAGTF-CE  LAN  configuration. 


3.3  ISSUES 

The  current  implementation  of  CSS/SCE 
Handles  tactical  data  and  record  messages. 

Does  not  have  voice  capability. 

Monitors  message-queue  sizes. 

Does  not  troubleshoot  any  communications  link  problems. 

Shows  developmental  costs  for  SAC  and  SIC  software  to  be  risky,  time-consuming, 
and  costly. 

3.4  RECOMMENDATIONS 

The  current  CSS  implementation  is  well  suited  to  a  MAGTF  CE  and  could  easily  be 
tailored  to  meet  Marine  Corps  needs. 

The  communications  requirements  of  a  MAGTF  CE  are  more  analogous  to  the 
requirements  supported  by  a  Navy  Computer  and  Telecommunications  Area  Master 
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Station  (NCTAMS).  Although  the  number  of  circuits  of  a  MAGTF  is  not  near  the  number 
at  the  NCTAMS  (5000  on  the  black  side),  the  number  of  circuits  is  certainly  much  larger 
than  those  in  Navy-numbered  Fleet  flagships.  Consider  the  use  of  the  MAGTF  Command 
Element  as  a  hub  for  the  SFF  SATCOM  GMF  net  to  DISA  and  the  Air,  Ground,  and 
Support  Command  Elements  with  a  parallel  architecture  of  wire  and  terrestrial  microwave 
links.  This  is  analogous  to  the  architecture  at  NCTAMS  EASTPAC  in  Hawaii,  where  the 
Navy  recently  installed  an  Automated  Network  Control  Center. 

This  is  a  true  implementation  of  a  Digital  Techcon  on  a  larger  scale.  It  consists  of  a 
8196-by-8196  true  nonblocking  black  switch  and  a  4096-by-4096  red  switch  with  switch 
servers  and  control  workstations  on  an  ethernet-based  control  LAN  (figure  3-3).  The 
switch  architecture  is  modular,  based  on  a  512-by-512  switch  and  a  64-port  Remote  Inter¬ 
face  Unit  (RIU);  it  can  be  scaled  and  packaged  to  meet  the  MAGTF/CE  deployed  require¬ 
ments.  The  RIU  uses  a  fixed  32-channel  TDM  scheme  of  32  channels  at  64  kbps  for  a 
2.048-Mbps  aggregate  that  can  be  run  2000  feet  on  twisted  pair  or  2  kilometers  on  fiber 
optic.  An  analysis  is  required  to  consider  the  cost  and  benefits  of  integrating  this  architec¬ 
ture  into  new  shelters,  existing  shelters,  and  consolidating  the  resulting  shelters  and 
equipment  to  achieve  the  following;  optimize  functionality,  enhance  survivability,  provide 
an  overall  space  and  weight  savings,  and  reduce  the  amount  and  weight  of  cable  required 
to  support  the  deployed  MAGTF  CE. 

Of  the  three  data  types  (record  message,  TACINTEL  data,  and  voice).  Marine  Corps 
record-message  traffic  is  the  most  straightforward  to  implement  in  a  CSS  architecture. 

Currently,  record  messages  are  handled  primarily  by  the  Rapid  Information  Manage¬ 
ment  (RIM)  Communications  System  deployed  in  an  AN/MSC-63A  Mobile  Comm  Shel¬ 
ter.  A  Navy  NAVMACS  (V)2  is  used  as  a  backup  delivery  system,  and  as  the  primary 
system  when  the  MAGTF  receives  its  record  traffic  over  UHF  Single-Channel  SATCOM 
as  a  CUDIXS  suscriber. 

3.4.1  Copernicus  Architecture  for  the  Common  Evolution  of  Navy  and  Marine 
Corps  Record-Message  Traffic  Delivery  Systems 

One  system  currently  under  development  is  the  NAVMACS  Model  H.  This  system  will 
eventually  replace  the  current  NAVMACS  (V)5  down  through  and  including  the  NAV¬ 
MACS  (V)2,  which  is  deployed  throughout  the  Navy  and  Marine  Corps.  The  system  is 
evolving  using  a  phased  approach,  which,  if  followed  properly,  could  be  tailored  as  appro¬ 
priate  to  maximize  benefits  and  minimize  cost  to  the  Marine  Corps. 

The  NAVMACS  n  uses  inexpensive  hardware  and  open-system  architecture.  It  cur¬ 
rently  uses  a  DTC-2  with  VME  backplane  and  the  UNIX  operating  system  and  will  use 
follow-on  standard  hardware  and  software  contracts  as  appropriate  for  time  of  delivery 
under  the  Copernicus  architecture. 
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MICROWAVE  RELAY 
OTHER  USERS 


Figure  3-3.  Automated  Network  Control  Center  (ANCC)  at 
NCTAMS  EASTPAC. 


The  starting  point  for  the  NAVMACS  n  is  the  MNFEP  for  use  at  Navy  Antisubmarine 
Operations  Centers  (ASWOC)  nominally  delivered  in  October  1991.  Phase  0  of  NAV¬ 
MACS  Model  n  was  successfully  demonstrated  in  USS  America  in  early  1992.  This  con¬ 
sists  of  using  the  NAVMACS  Model  n  as  a  front-end  processor  for  the  NAVMACS  (V)5 
on  the  CUDKS  link  running  at  9600  bps  instead  of  the  usual  2400  bps.  NAVMACS 
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Model  n  allows  9600-bps  operation  of  CUDIXS  on  both  UHF  single  channel  or  UHF 
DAMA  SATCOM. 

The  next  milestone  will  be  to  deploy  the  NAVMACS  Model  n  as  a  front-end  processor 
for  all  the  ships  in  the  USS  John  F  Kennedy  Battle  Group  to  allow  efficient  use  of  the 
assigned  9600-bps  SATCOM  channel. 

Delivery  of  the  Phase-H  software  is  scheduled  for  October  1992.  This  is  the  nominal 
point  at  which  all  the  functionality  of  the  NAVMACS  (V)5  is  supported  by  the  NAV¬ 
MACS  Model  n.  This  includes  guarding  circuits  other  than  CUDKS  (HF  full-period  ter¬ 
mination,  UHF  SATCOM  Broadcast,  HF  single-channel  full  duplex)  that  is  provided  by 
the  NAVMACS  (V)5.  Phase  n  also  includes  a  dedicated  local  area  network  (LAN)  for 
delivery,  storage,  and  user-initiated  random-access  retrieval.  This  capability  is  not  present 
in  the  NAVMACS  (V)5,  and  this  aspect  of  the  system  will  revolutionize  the  nature  of 
record  traffic  to  Fleet  users. 

NAVMACS  Model  n  is  being  developed  by  SPAWARS  PMW  152.  The  primary  field 
activity  is  NTSIC  at  Cheltenham,  Maryland.  The  development  milestones  have  been 
aggressive,  and  sometimes  the  plan  has  slipped  due  to  technical  difficulties  and  ship 
schedules.  Although  the  Model  n  was  not  developed  here  at  NRaD,  the  Marine  Corps 
would  benefit  from  having  NRaD  serve  as  its  agent;  i.e.,  NRaD  could  accept  a  copy  of 
deliverables  for  the  Navy  as  they  become  available  and  evaluate  them  for  modification  in 
a  laboratory  setting  and  for  later  demonstration  at  a  Marine  Corps  site.  We  feel  that 
minimal  modifications  would  be  required  for  the  circuit  side  of  the  NAVMACS  n.  How¬ 
ever,  the  Marine  Corps  might  want  the  delivery  system  rehosted  on  a  common-equipment 
LAN  of  its  choice,  and  they  would  definitely  need  to  tailor  the  message  routing  and 
internal  communications  functions  of  the  LAN  to  its  own  commmand  and  communica¬ 
tions  structure. 
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APPENDIX  A 


NAVY-DEVELOPED  C3I  SYSTEMS 

A.1  NAVY  TACTICAL  COMMAND  SYSTEM-AFLOAT  (NTCS-A) 

NTCS-A,  the  Navy’s  primary  afloat  Command,  Control,  and  Intellegence  System, 
provides  the  architectural  framework  for  initially  implementing  the  Copernicus  concept 
into  the  Fleet.  The  requirements  of  previously  separated  C2I  programs  are  planned  to  be 
satisfied  by  a  single  engineering  solution,  using  the  evolutionary  acquisition  approach. 
Examples  of  these  previously  separated  programs  are  JOTS,  TIMS,  POST,  EWCS,  NIPS, 
and  FDDS;  and  tactical  decision  aids  like  ASWTDA.  Features  associated  with  the 
NTCS-A  program  include 

a.  Standard  workstations— DTC-2  and  TAC  3. 

b.  Common  software  on  all  platforms. 

c.  Maximum  use  of  Non-Developmental  Items  (NDl)  hardware  and  Contractor- 
Off-The-Shelf  (COTS)  software. 

d.  Planned  formal  integration  of  functionally  related  prototypes. 

e.  Periodic  upgrades  of  baseline  systems  based  on  Fleet/user  inputs.  (A  Fleet 
Requirements  Working  Group  has  been  established.) 

Current  planning  indicates  that  integration  of  the  system  elements  mentioned  above 
will  be  completed  by  1994,  the  end  of  Phase  n  of  the  NTCS-A  program. 

Note:  While  additional  information  on  Navy  Command  and  Control  Systems  of 
interest  to  the  Marine  Corps  is  available  in  Chapter  4  of  the  U.S.  Marine  Corps  Command 
and  Control  Master  Plan,  be  very  careful  when  using  this  information,  since  many 
programs  have  changed  significantly  since  the  document  was  published. 

A.2  TACnCAL  INFORMATION  PROCESSING  SYSTEM  (TIPS) 

TIPS  is  a  general-purpose  information  storage  and  retrieval  system  designed  to  support 
the  needs  of  the  Marine  Landing  Force  and  Amphibious  Force  staffs  aboard  amphibious 
assault  (LHA,  LHD)  ships.  The  TIPS  component  of  the  ship’s  Combat  Direction  System 
(CDS)  Tactical  Data  System  (IDS)  supports  both  interactive  and  background  processing 
to  meet  tactical,  intelligence,  logistic,  and  administrative  requirements.  It  consists  of 
terminals  and  printers  located  in  strategic  areas  throughout  the  ship  to  provide  access  to 
its  predefined  databases.  These  databases  support  development  of  landing-plan 
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documents,  supporting-arms  reports,  and  management  of  embarkation  data.  Additionally, 
TIPS  is  to  be  used  to  create  and  manage  tactically  oriented  databases  to  coordinate 
operational  data,  including  aircraft  and  intelligence  data,  during  an  amphibious  operation. 
The  future  of  this  program  is  questionable  because  of  both  funding  and  technical  issues 
concerning  overlap  with  other  Navy  and  Marine  Corps  system  developments— particularly 
with  the  Marine  Corps  Amphibious  Assault  Planner  (AAP)  development  program. 

A.3  AMPHIBIOUS  ASSAULT  DIRECTION  SYSTEM  (AN/KSQ-1) 

The  AN/KSQ-1  system  program,  managed  by  NAVSEA  PMS  377,  is  designed  to 
provide  timely  three-dimensional  position  information  for  tactical  use.  The  system  is 
designed  to  provide  accurate  information  in  realtime  to  the  command  and  control  ships  of 
an  amphibious  task  force  on  the  position  and  movement  of  all  surface  landing  craft.  In 
addition  to  its  ability  to  display  and  disseminate  information  between  ships,  the  KSQ-1 
will  provide  both  a  secure-voice  and  digital-data  communications  link  for  these  ships.  This 
system  incorporates  the  Navy’s  Position  Location  Reporting  System  (PLRS)  capability  and 
is  being  designed  to  be  interoperable  with  PLRS— being  developed  by  the  Marine  Corps. 
The  program  plans  TECH/OPEVAL  in  late  FY  94  -  early  FY  95,  with  a  Milestone  RIB 
full-production  approval  decision  to  be  made  in  mid-FY  95. 
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APPENDIX  B 


OVERVIEW  OF  COPERNICUS  ARCHITECTURE 

The  basic  strategy  of  the  Copernicus  architecture  is  to  make  information  available 
where  and  when  it  is  needed.  This  is  a  significant  departure  from  the  “broadcast”  way  of 
conducting  communications  and  it  requires  a  supporting  structure  and  set  of  capabilities 
to  make  it  work.  The  stmcture  is  provided  by  the  four  major  pillars  of  the  architecture: 
(1)  the  Global  Information  Exchange  Systems  (GLOBDCS),  (2)  the  CINC  Command 
Center  (CCC),  (3)  the  Tactical  Data  Information  Exchange  Systems  (TADIXS),  and 
(4)  the  Tactical  Command  Center  (TCC).  The  GLOBIXS  are  virtual  networks  that  are 
essentially  very  high-capacity,  high  data-rate  pipelines  of  information  that  are  shared 
among  the  various  GLOBIXS  subscribers.  The  CCC  is  another  virtual  network  of 
subscribers,  tieing  together  existing  command  and  staff  organizations,  and  acting 
(through  the  CCC  “Anchor  Desk”)  as  a  switch  from  the  GLOBIXS  to  the  end  user  of 
information.  The  TADIXS  are  other  pipelines  (again  high  capacity  and  virtual  networks) 
between  the  CCC  and  the  end  user  of  information.  The  TCC  is  a  decision  center  for  the 
warfighting  commander.  This  TCC  should  be  designed  with  open-systems  architecture 
standards  and  modularity  that  can  be  configured  for  many  missions,  not  just  one.  The 
Copernicus  architecture  requirements  designate  a  MAGTF  as  a  TCC.  Likewise,  Corps, 
Air  Wings,  and  JTF  are  designated  as  TCCs. 

The  TADIXS  and  GLOBIXS  should  not  be  confused  with  existing  communications 
circuits  and  networks  that  are  essentially  bearer  services.  Instead,  they  should  be  viewed 
as  high-speed  and  high-capacity  switching  networks  that  facilitate  movement  of  informa¬ 
tion  from  where  it  exists,  to  where  it  is  needed,  when  it  is  needed. 
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APPENDIX  C 


CSS  TERMS  AND  DEFINITIONS 

CPG/SM— Communications  Plan  Generator/Security  Manager 
Has  an  interface  to  the  CSS-SCE  LAN. 

LARG— Link  Access  Radio  Group 

A  generic  term  that  represents  the  entire  suite  of  radio  communications  terminals  and 
equipment:  HP,  UHF,  EHF,  and  SHF 

RAC— Resource  Access  Controller 

Provides  an  interface  to  the  SCE  LAN  and  to  the  SAC,  and  handles  queueing  of  outgoing 
data 

SAC— Subnetwork  Access  Controller 

Provides  an  interface  to  the  RAC  and  a  particular  subnetwork  link,  and  handles  link 
protocols 

SCE— Standtird  Communications  Environment 

SCE  components  include  a  portion  of  the  SIC,  the  SPC/SM,  the  RAC,  and  the  network 
that  ties  these  components  together.  Non-SCE  components  include  the  TDP  Subscriber, 
the  TDP  subscriber  interface  of  the  SIC,  the  SAC,  the  cryptos,  and  the  LARG. 

SIC— Subscriber  Interface  Controller 

Provides  an  interface  to  a  particular  TDP  Subscriber  and  to  the  SCE  LAN. 

TDP  Subscriber— Tactical  Data  Processor  Subscriber 
Some  Marine  Corps  examples  will  be  included  here. 
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